[wsf-c-dev] [wsf-php] RM API

[Samisa Abeysinghe]

nandika wrote:
> hi all,
>
> For adding reliable messaging support to we need to add following.
>
> *Client Side*
>
> Additions to WSClient  Options array.
>
> 1) Enabling RM and specifying RM version
>  
> "reliable" => TRUE | 1.0 | 1.1
>
> 1.0 for RM  version 1.0
> 1.1 for RM  version 1.1
> Default RM version will be 1.1 , If user specified TRUE , rm  version 
> will be 1.1.
I thought we cannot support RM 1.0 with PHP. Same channel is in 1.1, and 
we could support dual channel with PHP (and I don't think we should) .
So does it make sense to have 1.0 in option list?
>
> In addition , user should have specified required addressing options 
> for RM to be enabled.
What addressing stuff are required? Can we enable those by default if RM 
is in use?
>
> 2) Whether to offer a response sequence.
>
> "offer" => TRUE | FALSE
>
> Default value is FALSE.
"offer" does not indicate that is it talking about  "response sequence", 
shall we use "response_sequence" instead?
>
>
> 3) Identifier for sequence
>
> "Identifier" => "unique identifier key"
>
> If this is not specified, a key will be generated internally.
Why "Identifier" and not "identifier"? Again, I think identifier is too 
generic. It does not indicate it is an RM option. What if we use 
"sequence_identifier"?

Also, as we support more and more spec and we introduce more options, 
would it not be a good idea to have a prefix to indicate which spec this 
option belongs to?
e.g. "rm_sequence_identifier",  "rm_response_sequence" etc.
>
> 4)
> Need a way to specify when to send the "TerminateSequence" message.
> This we can't do with options array as this option should be set after 
> multiple calls to
> $client->request() function.
>
> We came up with three possible options.
>
>     i) add a functions setLastMessage(TRUE|FALSE) to WSClient
>           default will be FALSE
What would setLastMessage(TRUE) do? and What would setLastMessage(FALSE) do?
Do we need a parameter at all?
Why not have a function like $client->rmTerminate(); ?
>
>     ii) add a function setOption() to WSClient.
>         setOption(array of options)
I cannot remember the reason exactly but I think we decided not to have 
such a function at some point. Anyone remember why?
>
>     iii) add an optional argument array to WSClient's   'request' and 
> 'send' functions so that request
>         and send functions will be as.
>                        request( mixed payload [, array of options])    
>                   
>                        send( mixed payload [, array of options])
>           
>            -this allows us to  specify this 'request | send ' specific 
> options.
This looks OK. However, how often are we going to need this sort of 
request/response specific options? If it is occasional (and as of now, 
we only have the RM case) we better not use this and add unnecessary 
noise to request, send methods.
>
>   All of these allows us to specify to the WSClient object to send the 
> "TerminateSequence" after the application message.
>    If we go for one of last two, we can use
>             "lastMessage"=> TRUE | FALSE    for the options array 
> specify that current application message is the last message
>
>     What is the better solution or is there a better way of doing this ?
>
>
> *Server Side
> *
> Additions  to WSService object constructor's options array
>
> To engage RM for server side
> "reliable"=> TRUE
>
> addressing should also be engaged.
Again, can we engage addressing by default if RM is already engaged?

Samisa...