> > Hi Paul, > Glad to see this back .. been thinking of it recently. There were a few things that came up on the old thread that are still a bit open ended imho :o)
1. Are we still going for service level scope for this ie all the operations on a service? 2. You previously wanted to allow this to be turned on/off for request and responses to imitate the pattern in MQ or JMS to have a temporary reply to a persistent message. Is that still the plan? 3. Adding a policy assertion cannot guarantee the messages are written to disk. It means that this is the intention, but this is different to adding security headers to messages for example, which would be verifiable by the message. The client has to trust the server to do what it says and vice versa which is ok but we should be clear about this. but, to split some more hairs, are we abusing policy in some way by adding this kind of assertion that can't be verified? 4. How are we defining persistent? Paul you referred to XA spec which from a quick scan frequently assumes a database or file system as the storage but this was written in pre-historic times. Do we need to define what we mean by persistent, ie kinds (database or file system), recoverability quality (after server failure, time based). This becomes a rabbit warren to start down, but makes point 3 more important as if we can't define what we require when someone says they are persistent, then users of this can't be certain what they are getting when they add the xml to their message. This could then be seen as overhead on the message that adds limited value? I don't want to be a nay-sayer here .. I think persistent RM is valuable. I just want to make sure we aren't adding something because we can, rather than because we need to. thanks, Sara
