[SAGA-RG] Message API Evolution

[Andre Merzky]

Hi all, 

alas, there was not much feedback on the messaging API options.  So,
we'll go forward with the generic endpoint version for the time
being, and will re-evaluate that designe decision once we get to the
experimental document, and the final specification.  I'll add a
respective statement to the document before it goes into final call.

Thanks, Andre.


Quoting [Andre Merzky] (May 10 2010):
> 
> Dear Group,
> 
> the Messaging API originally evolved around a single endpoint class,
> whose behaviour was, together with the endpoint's URL, determined by
> a number of properties, all specified on creation time.  In order to
> satisfy the relatively wide range of use cases, the number of
> properties was rather large, and included
> 
>   - communication topology
>   - message reliability
>   - message delivery atomicity
>   - message correctness/completeness
>   - message ordering
> 
> (All properties can be left unspecified, and the URL schema can
> pinpoint a specific protocol and transport medium to be used.)
> 
> Additionally, the API proposal contained a message class, which is
> derived from saga::buffer, and allows to add application level
> structure to that SAGA buffer.  That message class also provides
> some means of inspection (message origin and id, and generic user
> level attributes MAY be available on the message instances).
> 
> There was some feedback (at OGF and on this list) that this API, and
> in particular the endpoint class, may be cumbersome to use (too many
> degrees of freedom), and that the ability to specify incompatible
> endpoint properties (e.g. 'Unreliable & ExactlyOnce') was confusing.
> 
> There are, however, not many obvious ways how to remedy those points
> without blowing the API out of proportion, or loosing coverage for
> specific use cases.  The examples attached to this mail illustrate
> the different possible approaches:  they contain the respective API
> prototypes, and a short code example, which creates a visualization
> pipeline segment (communicating a geometry between mapper and
> renderer).
> 
> We are mentoring a google-summer-of-code student at LSU at the
> moment (Hi Christos!), and his task is to provide a prototype
> implementation of the message API.  I would thus propose to have a
> quick vote on one of the proposals below, to allow Christos to go
> forward with the resulting option (remember: "rough consensus &
> running code").  Once we have running code and a matching proposed
> recommendation, we have two years time to gather experiences with
> that, and should be prepared to switch to any of the other options
> on the final recommendation, if needed.
> 
> So, please provide feedback to the following options, or provide
> alternative options.  FWIW, I also attach the current (generic) API
> proposal again.  Both the proposal and the code examples can be
> found in svn, at
> 
>   https://svn.cct.lsu.edu/repos/saga-ogf/trunk/documents/saga-package-messagebus
> 
> Thanks, and best regards, Andre.
> 
> 
>   (A) generic.cpp
>    
>     The orginal API proposal, which described a single endpoint
>     class with multiple properties.
> 
> 
>   (B) specific.cpp
> 
>     Specifying individual endpoint types for specific use case
>     classes makes those endpoints simpler (most properties are
>     preset), but also makes use case coverage difficult (one cannot
>     sensibly cover the complete property-space with individual
>     classes).
> 
> 
>   (C) topology.cpp
> 
>     Specific individual endpoint classes for the different
>     communication topologies also blow the API, to some extent, but
>     also reduce the number of explicit endpoint properties (from 5
>     to 4).  One could also consider to have different property
>     presets per topology class (like 'Unrealiable, Unordered' for
>     'PeerToPeer' endpoints, and 'Reliable, Ordered' for
>     'PointToPoint' endpoints), but that may be confusing to the
>     unaware end user.
> 
> 
>   (D) mixed.cpp
> 
>     Another possible approach is to mix elements from the approaches
>     above: the API could include a generic_endpoint class, but also
>     topology specific endpoints, and/or use case class specific
>     endpoints.  That may address all levels of end users, but would
>     also convolute the API significantly.
-- 
Nothing is ever easy.