Hi group, Ole prompted me for an update of the state of the Message API. Instead of just answering him, let me post the state of affairs to the list. It would be great if we could get the ball rolling on this one again - we have a number of pending use cases which *really* could make use of a SAGA Message API extension - but the spec discussion has stalled for quite some time. So, here is a summary of the state and current problems, and also a rough roadmap. The lates draft is also attached. Cheers, Andre. ----------------------------------------------------------------- The API draft proposes an univeral communication endpoint, which has a set of properties (topology, reliability, ordering etc etc). Those properties basically nail down the set of applicable implementations/protocols. As examples: - 'reliable verified exactly-once ordered point-to-point' --> plain tcp (+ some message protocol on top) - 'reliable unordered exactly-once unverified publish-subscriber' --> IRC, twitter, ... - 'unreliable unordered unverified point-to-point' --> plain udp (+ some message protocol on top) The feedback was that - this single endpoint class looks complex, and covers lots of semantics - the range of possile flag combinations will result in many invalid ones (or at least not-implemented ones) However, there were no good alternatives forthcoming: the known alternatives have drawbacks of their own: - add specific classes for the various topologies, like a point-to-point-endpoint, a multicast-endpoint, etc + less cluttered classes + some properties can be fixed per class - invalid / not implemented combinations still frequent - not easily extensible (new class instead of new enum) - limit the set / range of available flags + less chances for invalid flag combis + simplier endpoint class, with more focused semantics - hard to define what flag set covers most use cases - flags themself seem minimal already, its the combination which blows the semantic space up The latest procedural proposal was to write down a set of dummy examples for some use cases, and to see how easy/difficult the proposed variants are to use. That code was supposed to get posted on the mailing list, and to get discussed and voted on. I never got around doing that :-/ Anyway, this is where things are. I personally think that the criticism of the draft is very valid, but I don't see the options above improving things really. I am biased though... A possible compromise may be an additional set of constructors which create endpoint instances for the most common use cases, like an 'tcp like' endpoint etc. That however blows up the API again, to some extent. So, what are the current action items / milestones: - any feedback is useful - thinking about other alternatives than the ones above - writing up those examples - get rough consensus on any one of the known alternatives - fix the draft according to vote - get draft published to allow implementations - be prepared to get back to the drawing board based on implementation experience Cheers, Andre. -- Nothing is ever easy.