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

[John Taylor]

Sorry not to have been keeping up with this: as Mike noted, I'm  
"away" this week.

It looks like we're splitting into two camps: those who want to get  
as close to perfect a design as possible up front so we don't have to  
throw anything away in the future, and those who want to get code out  
there reasonably quickly to get feedback and direction from the  
astronomers.   It won't be any surprise if I declare that I'm in the  
latter camp.  However, I don't think either side is going to persuade  
the other of its righteousness as, let's face it, there are pros and  
cons to both approaches.

So, as Tony says, why can't we do both?

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.

I think a) is actually not true.    It buys us time to get the Grand  
Messaging Architecture right.  By getting messaging software into the  
hands of astronomers early we'll get valuable feedback and experience  
that we can feed into the design of the  GMA and will even save time  
overall.
As for b), this can be mitigated by VOOOM=PLASTIC++ having an IVOA  
stamp on it, giving a clear roadmap for when the GMA is likely to  
appear and pledging to continue to support VOOOM in our applications  
for some transitional period.

If we started now, we could get a working draft out not long after  
the May interop.


John




On 16 Apr 2007, at 21:19, Tony Linde wrote:

>>     Certainly it was the success of PLASTIC that started the
>> discussion,
>> but I believe our mandate here is for an 'applications
>> messaging standard'
>> and not simply a cleaned-up PLASTIC.  To the extent PLASTIC
>
> Why can we not have both? The 'cleaned up PLASTIC' *ought* to take  
> a lot
> less time and could be agreed before Sept. In parallel and carrying  
> on from
> that, some more formal and extensive messaging framework could be  
> worked on.
> As long as all apps developers know that the new std will replace  
> and make
> obsolete the old one with no guarantee of backwards compatibility  
> then there
> should be no problem.
>
> The longer this debate continues, the more likely that Plastic will  
> become a
> de facto std like cone search: and that will definitely happen if  
> we try to
> formulate a complete messaging framework from the off. It would be  
> better if
> the IVOA had a hand in the 'cleaned up PLASTIC' though.
>
> Or, we could simply accept that PLASTIC *is* the de facto IVOA app- 
> interop
> standard and leave it to the people using and defining that to  
> develop the
> 'cleaned up PLASTIC' standard.
>
> T.
>
>> -----Original Message-----
>> From: owner-apps at eso.org [mailto:owner-apps at eso.org] On
>> Behalf Of Mike Fitzpatrick
>> Sent: 16 April 2007 11:54
>> To: apps at ivoa.net
>> Subject: Re: Apps Messaging - Semantics of a Message
>>
>>         This thread is long enough already so please forgive me for
>> mixing replies to several messages to respond to just a few points.
>>
>>
>> Noel writes:
>>
>>> It is my understanding that it was the real-world success of
>>> plastic that piqued IVOA's interest in messaging. I talked to
>>> several of the exec whilst at moscow - the impression I got was
>>> that their desire was for a plastic-like cleaned-up international
>>> standard.
>>
>>     Certainly it was the success of PLASTIC that started the
>> discussion,
>> but I believe our mandate here is for an 'applications
>> messaging standard'
>> and not simply a cleaned-up PLASTIC.  To the extent PLASTIC
>> can evolve to
>> meet the needs of all apps then that is a valid path, but
>> we've already
>> identified several use-cases (both specific and more general
>> philosophies)
>> where this becomes a problem eventually.  If PLASTIC didn't
>> already exist
>> I think everyone would be happy with a quick implementation that does
>> the plastic-like messaging *so long as* we had a basic
>> framework where the
>> other cases could be added easily later on.  Knowingly
>> excluding a certain
>> set of use cases because what's in use is "good enough for now" is  
>> not
>> the best we can do.
>
>
> http://www.Taglocity.com Tags: IVOA, apps,
>