[SAGA-RG] mesage API

[Thilo Kielmann]

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.)

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

--
Thilo Kielmann
http://www.cs.vu.nl/~kielmann/