Re: Apps Messaging - Twin track?

From: John Taylor <jontayler-at-gmail.com>
Date: Mon, 23 Apr 2007 17:34:36 +0100

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
>>
>>
>
Received on 2007-04-23Z18:35:13