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.
attachement of course... :-P Quoting [Andre Merzky] (Apr 08 2010):
Date: Thu, 8 Apr 2010 00:39:58 +0200 From: Andre Merzky <andre@merzky.net> To: Ole Christian Weidner <oweidner@cct.lsu.edu> Cc: SAGA RG <saga-rg@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.
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@merzky.net> To: Ole Christian Weidner <oweidner@cct.lsu.edu> Cc: SAGA RG <saga-rg@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@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
-- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
Quoting [Thilo Kielmann] (Apr 08 2010):
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.)
Indeed, the message API has been put on a backburner because of the exp document and the errata. But those are basically in final call now, and I am ideling ;-) Best, Andre.
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@merzky.net> To: Ole Christian Weidner <oweidner@cct.lsu.edu> Cc: SAGA RG <saga-rg@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@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
-- Nothing is ever easy.
participants (2)
-
Andre Merzky -
Thilo Kielmann