vote on Proposed changes to PLASTIC for 1.0

[Doug Tody]

Hi Mark -

I have only time for a quick response.  What you describe looks
reasonable except that the core thing is not a "messaging data model"
but a "messaging model".  It is as much about the messaging semantics
(delivery options etc.) as about the information content of the core
message container.   I guess we just get too used to talking about
data models, but system modeling is not the same thing.

Probably what is needed in an architecture and design for the core
messaging model, plus at least two protocol/API specifications with
associated implementations.  This is 2 and 3 in your note below.
I agree that these can't be complete separated, at least in the sense
that one can't be confident of a specification without implementations.
One of these implementations would be a PLASTIC-like API, another could
address other use cases such as general messaging with other content
models via a container API.  The point would be to demonstrate some
degree of interoperability upon the same core messaging implementation.

In terms of schedule a reasonable goal might be to have a start on
this for the fall interop, with early implementations and a more
complete specification within a year (probably following on from the
fall interop).

	- Doug


On Fri, 11 May 2007, Mark Taylor wrote:

> 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/
>