Apps Messaging - Twin track? [was: Re: Apps Messaging - Semantics of a Message

[John Taylor]

Hi Mike,

On 17 Apr 2007, at 06:25, Mike Fitzpatrick wrote:

> On Tue, 17 Apr 2007, John Taylor wrote:
>
>> In fact, we already are: people have been defining new PLASTIC
>> messages and finding new uses for the system even as we've been
>> discussing its "successor".  It would be helpful to formalise this
>> though.
>>
>> What are the disadvantages of the twin track approach?
>> a) Extra work - we end up doing things twice.
>> b) App developers might not adopt the preliminary spec, but will wait
>> for the final one.
>
> 	You forget "c) Developers may not see a need to move to the
> 'GMA' and we end up with competing specs".  I think this is the most
> likely outcome and only turns the useful debate we're having now into
> a pissing contest about who's messaging system is better.
>

I'd assumed that we'd deprecate the old one, and that by and large  
developers would support an IVOA-mandated spec over an unofficial  
one, all other things being equal.  And they shouldn't be equal - the  
new one ought to be better and allow a greater range of tools to talk  
together (otherwise what's the point?)
Currently Ray's group are moving over to a new registry standard, and  
as far as I know groups aren't saying "no thanks, I'll stick with the  
old one" - the new one allows them to do more things with their  
registry, so they adopt it (albeit slowly due to work constraints).   
I know we (AstroGrid) have anyway.



> 	While I think it is primarily a distraction at this point, I
> must admit I'd be curious to see what a 'cleaned-up plastic' would
> look like.  This would need to address the points raised so far and
> incloude a roadmap to "transition" to the new system, if it only  
> widens
> the gap it won't help things much.  Perhaps a consensus of what this
> looks like reached on the plastics-dev list and put forward as an
> alternative plan??
>

Sure, we can do that, although I think we've made a good start on  
this list.  Pierre just highlighted a few things that he'd like to  
see.  Off the top of my head, my own shopping list would include  
Pierre's:
*  drop/make optional the JavaRMI transport
*  swap IVORNs for mtypes [if we can agree some of the latter quickly  
enough
and also
* make message parameters untyped (in the int vs string vs double sense)
along with the changes to the API already suggested
* split and rename some operations
* remove synchronous messaging
* add some security.


>> If we started now, we could get a working draft out not long after
>> the May interop.
>
> 	The premise with this and similar statements is that we have
> *nothing* and this point and so time is critical, it usually comes in
> a message that likewise says we already have plastic so why move on.

It's not that we have nothing, just that what we have has some flaws  
that we'd like to fix, and these changes are stalled pending  
agreement in this forum.  Also, I think there are developers who  
won't risk adopting PLASTIC because it might go away tomorrow, who  
might have more confidence in something with an IVOA sticker on it  
(which is not unreasonable.)

So, for a messaging protocol we have something, for an IVOA standard,  
we have nothing.

> Calling a/the new system 'Grand' and 'extensive' certainly helps make
> it seem more trouble than I think we're really talking about, but 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.

My choice of name wasn't supposed to be pejorative: everyone here is  
far too smart to be influenced by such a cheap trick.  If you can  
think of a label for the simple protocol that's mildly amusing and  
insulting (Simple Hacked Inter Tool System?), I'll happily adopt it.

As for it not satisfying your requirements, I'd be very keen to see  
what we can do to get the protocol working with IRAF, even if  
imperfectly.  It would certainly help me understand how we could make  
the Mk II protocol work better for you.

John