[SAGA-RG] mesage API

[Andre Merzky]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: saga_messages.pdf
Type: application/pdf
Size: 241512 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/saga-rg/attachments/20100408/afb5f906/attachment-0001.pdf