vote on Proposed changes to PLASTIC for 1.0

[Mark Taylor]

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 at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/