[SAGA-RG] Message API Evolution

[Andre Merzky]

Hi all, 

attached is the lates draft of the SAGA messaging API extension.  We
intent to submit that draft to the OGF Editor pipeline as is in
about a week from now, unless we see comments to the contrary on
this list.

Thanks, Andre.



Quoting [Andre Merzky] (May 18 2010):
> 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: saga_messages.pdf
Type: application/pdf
Size: 236470 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/saga-rg/attachments/20100518/14e3bbaa/attachment-0001.pdf