Apps Messaging - Twin track?

[John Taylor]

On 23 Apr 2007, at 17:09, Doug Tody wrote:

> Hi Mark -
>
> 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.


Hi Doug - that was the point.  I seeded the list with things that  
PLASTIC is able to do as it seemed a reasonable assumption that any  
successor  protocol would be able to do at least as much.  In my  
email announcing this wiki page I asked for contributions from people  
who had experience of other systems.

John




>
> 	- Doug
>
>
> On Mon, 23 Apr 2007, Mark Taylor wrote:
>
>> Mike,
>>
>> On Mon, 16 Apr 2007, Mike Fitzpatrick wrote:
>>>                                                                    
>>> I put
>>> myself in John's 'perfect design' camp not because I crave  
>>> complexity,
>>> but because plastic does not satisfy MY requirements (actual as well
>>> as what I believe is needed for apps other than simple tools) for a
>>> messaging system.  If a plastic roadmap can't fix that, I guess I'll
>>> never see the charm in it.
>>
>> apologies if we've covered this already and more recent parts of
>> the debate have displaced it in my short term memory, but can you  
>> give one or more examples of which messaging requirements you have
>> which cannot be satisfied by PLASTIC?  It would be good to add a use
>> case or two which fits this description to the wiki page:
>>
>>   http://www.ivoa.net/twiki/bin/view/IVOA/ 
>> ApplicationsMessagingUseCases
>>
>> so we can make sure that whatever we end up with does actually solve
>> the problems which we need solved.  I've just (belatedly) added one
>> of my own which represents one of the scenarios which PLASTIC can
>> handle well and which I think it's important that any replacement of
>> it can do too.
>>
>> Mark
>>
>>
>