Danushka I'm not clear I understand your point.
Firstly, I was just using AMQP as an example - I didn't mean that we wanted to be exactly the same as AMQP or do anything with AMQP. So firstly, in general, I don't believe that Sandesha2 can modify the persistence on a sequence by sequence basis - either it is on for a service or off. However, logically the sequence *is* the level at which persistence can be defined. So these are the options I see: * The server has persistence set permanently on for a service. It does not demand persistence from the client. It publishes a policy saying persistence is optional for the client. It accepts any sequence creation, and persistently stores messages. If the client "asks for persistence" during the create sequence, then it says "yes I'm persistent in reply" (by some yet to be determined mechanisms). This is how we operate today, except with the addition of the policy and the optional information passing during create sequence. * The server has persistence set permanently on for a service. It demands persistence from the client. Therefore it publishes a policy saying that client's must be persistent. During the CreateSequence exchange, it can refuse any client that doesn't agree (by some yet-to-be-defined mechanism) to be persistent. This would be a new capability. * The server has some clever ability to turn persistence on or off per-sequence based on the create sequence. In this model, the server picks up the preference from the client. So the same service might have some persistent and some non-persistent sequences. Maybe this is overkill and beyond the basic requirements. I'm not clear. However, this seems to be a model that other systems allow. Of course, a server could respond that it doesn't support this capability. Ideally, all of this would be designed to allow backwards compatibility. So even in the cases where the server refuses a sequence because it requires persistence and the client doesn't support this extension, the failure is explained in the error and the administrator can see why. Paul On Mon, Jun 16, 2008 at 12:20 PM, Danushka Menikkumbura <[EMAIL PROTECTED]> wrote: > >>>> 1) A policy element to indicate whether this endpoint supports and/or >>>> requires persistence >>>> >>>> >>> >>> (b) Even if we go for transport level persistence, the endpoint does not >>> have a say in it, because in AMQP we can have either queue level >>> persistence >>> (i.e. transport receiver level abstraction) or message level persistence >>> (i.e. message sender level abstraction). >>> > > Hi Paul, > But still this is not doable with AMQP. > > Danushka > > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
