[SAGA-RG] mesage API

[Andre Merzky]

Quoting [Thilo Kielmann] (Apr 08 2010):
> 
> Sorry to disagree.
> The SAGA group already has too many loose ends to fix.
> 
> We must get the errata and experience documents out of our way first,
> as they currently block all other efforts. (Please no new construction  
> sites
> until the previous ones have been cleared.)

Indeed, the message API has been put on a backburner because of the
exp document and the errata.  But those are basically in final call
now, and I am ideling ;-)

Best, Andre.


> 
> Thanks,
> 
> Thilo
> 
> On Apr 8, 2010, at 12:40 AM, Andre Merzky wrote:
> 
> >attachement of course... :-P
> >
> >Quoting [Andre Merzky] (Apr 08 2010):
> >>Date: Thu, 8 Apr 2010 00:39:58 +0200
> >>From: Andre Merzky <andre at merzky.net>
> >>To: Ole Christian Weidner <oweidner at cct.lsu.edu>
> >>Cc: SAGA RG <saga-rg at ogf.org>
> >>Subject: mesage API
> >>
> >>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.
> ><saga_messages.pdf>--
> > saga-rg mailing list
> > saga-rg at ogf.org
> > http://www.ogf.org/mailman/listinfo/saga-rg
-- 
Nothing is ever easy.