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