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

[John Taylor]

On 17 Apr 2007, at 22:46, Doug Tody wrote:

> On Tue, 17 Apr 2007, John Taylor wrote:
>
>> 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.
>
> Judging from this sweeping list of possible changes to PLASTIC from
> John, and the statements some of us have already made that PLASTIC
> as it stands is too narrowly focused to adequately address the needs
> of the broader community which a general astronomical applications
> messaging standard must serve, it seems pretty clear that this matter
> is not yet close to reaching closure.  The changes above alone would
> require an updated document and implementations, which would likely
> take us until at least sometime into the summer to complete.

I think we can do it faster than that - it's just a clean up of what  
we already have.

>
> It is not clear to me why this is so urgent, to the point where
> getting something out quickly trumps doing a good job.

Because with IVOA backing, we will be able to get more application  
developers on board, we'll get feedback and new ideas sooner, and  
ultimately a better spec then we'll get by trying to sort it all out  
upfront.  Plus the astronomers get the benefits in the meantime.  And  
I wasn't actually expecting us to do a bad job.


> This sense of
> urgency is being driven primarily by the current developers and users
> of PLASTIC, which are only a subgroup of the broader community now
> involved.

Well, to be fair, there aren't many voices arguing against.  Most  
people who've expressed an opinion on this list want us to move this  
forward quickly.

> But these users already have PLASTIC, which can continue
> to serve this community, possibly with some enhancements inspired
> by our discussions here, while the broader applications messaging
> standard is developed.

In that case the only thing we might disagree on is whether PLASTIC++  
should become an intermediate standard while a fuller one is thrashed  
out.  I believe it should, to encourage developers across the IVOA to  
use it.  Indeed, this is the only way we will get all the feedback we  
need to develop its successor.

>
> Furthermore, while I agree that PLASTIC has been very successful and
> has demonstrated an important new approach to desktop application
> interoperability, the project has basically been pursued thus far
> via a rapid prototyping approach.  The logical next step in such
> a rapid prototyping effort is refactoring, to adjust the design to
> reflect what has been learned.  The scope of the effort has changed
> somewhat in the meantime.  All of this suggests that we are not yet
> close to having an actual standard which can remain stable for a time.
> At best we have a functional prototype which be frozen and used for
> some months while the next version is under development.
>
> Perhaps what is needed is an updated PLASTIC document, which attempts
> to define a PLASTIC interface which is closer to what we think we
> may ultimately end up with, plus an ongoing effort to define a more
> general astronomical messaging standard.  One requirement for this
> would be that it continue to provide something similar to PLASTIC,
> with similar ease-of-use and interface, to serve the current class
> of applications which now use PLASTIC.  With all the effort which
> has already gone into this, it may be possible to have a preliminary
> specification and some initial implementations working by the summer
> or fall, hopefully with all of us participating this time.
>
> 	- Doug