Apps Messaging - Twin track?

[Alasdair Allan]

Doug Tody wrote:
> I think the point of these use cases should be to scope out what we
> would like a general applications messaging protocol to do, rather  
> than
> analyze the pros and cons of the current PLASTIC.  On the other hand,
> in defining a "SAMP 1.0", it probably is reasonable to limit this
> primarily to the sorts of things which PLASTIC is currently used for,
> so long as this is seen as a step towards a more general applications
> messaging protocol.

I think the point Mark is trying to make, and please feel free to  
jump up and down and hit me around the head with various items if I'm  
misunderstanding here Mark, is that he hasn't seen any uses cases yet  
which PLASTIC doesn't address. I'd tend to agree. To quote...

Mark Taylor wrote:
> However, for those of us who are used to thinking in PLASTIC terms  
> it would be useful to get (and put somewhere for future reference)  
> concrete examples of messaging problems which need to be solved and  
> are not soluble using the existing PLASTIC system, alongside some  
> which are. I'm afraid after all this debate, although I have a  
> clear idea of (and some sympathy with) your unease with the lack of  
> design clarity underlying PLASTIC, I still don't have a clear idea  
> of the ways it fails to adress the real life use cases that you've  
> got in mind.

I also am not sure of the need for a more general applications  
messaging protocol. In fact unless we can come up with a killer use  
case that something along the lines of PLASTIC can't do, I'm totally  
against a more general approach to the entire problem.

A general approach will undoubtedly complicate the lives of  
applications developers, and that something I desperately want to  
avoid. I don't think we should put extra load on application  
developers just because it makes the architecture more elegant.

I really think 'simple' should be our goal, not 'general' which (in  
general) is never simple.

Al.