Jaliya
> But from the client perspective, there are a few options: > > 1) Do we want to make an offer? Not a must but if the client sends it we need to accept it.
+1. There seems to be a situation with Indigo where you need to send an offer if there is going to be 2-way RM. So having a way of forcing Sandesha to send an offer is important.
> > 2) Do we want a separate listener - at the moment Sandesha doesn't > support two-way RM with an anon endpoint for RM1.0, because its not > really speced. Of course this is really an endpoint setting > independent of RM. > My idea in this aspect is yes. I am still not sure why we need RM if the messages are strictly request/response and almost real time.
So in RM1.1 we have the MakeConnection model, which allows an asynchronous message interaction over HTTP.
In addition as you have mentioned in the below it is always good to support the use of a listener that is available (say the RM Client is running inside some container)
Yes
> 3) Do we want to use RM1.0 or RM1.1 > > 4) [Advanced] Do we want to set an internal SequenceKey? This could be > used to ensure that for example different clients used different > sequences. +1. > > 5) [Advanced] Do we want to set a sequence expiry? > Could you please explain a bit more?
I'm talking about setting: <wsrm:Expires ...> xs:duration </wsrm:Expires> in the CS message. Actually this is a setting that applies to the server as well. Basically I might want to set a short expiry duration for some sequences. -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
