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. Received on 2007-04-23Z20:06:16