Re: vote on Proposed changes to PLASTIC for 1.0

Doug Tody wrote:

> I looked at this, but it appears to concern only near-term changes
> to PLASTIC, which is mostly a concern of the folks currently using
> PLASTIC who will be impacted by these changes. It is a good thing
> to move PLASTIC more in the direction we think we are going longer
> term, but my main concern (and probably a few others like me) is what
> happens next. All I suggest is that the roadmap might also include a
> follow-on effort to address the more general applications messaging
> problem (this can continue to retain support for a PLASTIC-like
> capability), and that this go foward after PLASTIC 1.0 is out,
> including both design and prototyping.
>
> - Doug

Doug,

thanks for keeping the longer term issues on the agenda. As you've gathered, for the immediate future (decisions at this interop hopefully leading to a specification document draft and some implementations before the next interop) the intention is to produce something which is more like a tidied and improved version of PLASTIC than a fully general messaging system which will be able to serve all the uses which have been discussed. We hope however that the near-term goal will incorporate some of the ideas which have come out of the recent debate and move in the direction of compatibility with the longer-term requirements that you have in mind.

As you say, the Apps WG roadmap should include an idea of the longer term direction. The next steps would presumably be along the lines of:

1. A document describing architectural issues/requirements for a general messaging system, including something like a "messaging data model", although I don't think that this needs to resemble in form (or length) the kind of thing generated as part of the IVOA DM effort. This could either be drafted as a formal specification (on the WD->PR->R track) in one go, or take the form of an informal Note marking out some of the important issues and requirements, to be followed by a formal specification at some later date.
2. A document describing one or more particular implementations or profiles of such a system, in the sense of defining concrete APIs, bootstrapping procedures, wire protocols etc.
3. Some working code which implements (a) the infrastructure ("hub"?) and (b) applications using it to perform useful messaging.

(The PLASTIC approach has been to conflate (2) and (3). I still see this as a reasonable thing to do, but I appreciate that for the purposes you've got in mind you want to keep them separate).

In an ideal scenario, the specification which we are aiming to finalise at Beijing and to write up subsequently would require only minor changes in order to qualify as an instance of (2), while other instances of (2) fulfilling other particular requirements could be developed as required. This is no doubt a bit optimistic, but it's something to aim for and I hope you don't think it's totally fanciful.

If you agree with this general outline, I'd like to hear what kind of timetable you think is sensible, especially for item (1). There would be some advantages in it going forward concurrently with the post-Beijing specification, but I don't think it's essential. You have clearly thought more about, and are more motivated to move towards, the generalised scenario than most of the others in the debate (myself included), so you would probably have the most input into it. If on the other hand you think some different approach is required to take this forward, I'd welcome your suggestions.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/