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.
