Mike,
On Wed, 18 Apr 2007, Mike Fitzpatrick wrote:
> We seem to have reached a stalemate, or at least an unproductive
> state, in the discussions and so it may be time to try a different approach.
>
> My sense is that we would all be happy with an intial version of
> the spec that at least retains (and ideally improves) the current PLASTIC
> capability for current high-level tools to interoperate, but also recognizes
> that there are valid use cases that might not be handled in the first
> version and will be fixed later (perhaps involving significant changes).
> We've so far been working at this from the perspective of writing a
> spec from scratch with the idea of incorporating PLASTIC abilities into
> the new framework; what I'd like to suggest is that we explore the
> "cleaned-up Plastic" angle to see if we can make more headway by trying
> to turn PLASTIC into a v1.0 spec we can all live with. Note what I'm
> suggesting is still more than just a PLASTIC v1.1, but we use a different
> starting point in the discussion (and put the burden on the PLASTIC folks
> to propose a roadmap that everyone else can buy into instead of asking
> them to buy into a new idea).
Sorry I haven't responded properly to this before now. It does seem that between your and John's contributions we appear to be heading somewhere constructive - good!
John has considered backwards compatibility on the PlasticOnePointOh wiki page, and I think I agree with his assessments, namely that it will be possible to move from the existing PLASTIC spec to something with these features without anything major breaking, though it will require some messiness in the interim. However, both for hub implementations and for client applications there will be some effort required to effect the change. I'd like to keep the effort expended implementing such changes (integrated over time) as low as possible, and in particular attempt to ensure that any future changes are as painless as possible at the level of application (and to some extent hub) implementations. What I want to avoid is expending considerable effort on moving to PlasticOnePointOh now and having a similar, or greater, level of effort required in the medium-term future in order to upgrade to a more general purpose messaging system that is, or is compatible with, what Mike and Doug have in mind. One big step would be better than two medium-sized ones (or indeed two big ones).
So although I'm in favour of keeping things reasonably similar to
what we have in order to get capability improvements in the short
term, in my view it's worth expending some additional time as required
now to ensure (at least, to increase the probability) that what
we come up with will be compatible with the future requirements.
>From what I understand of Doug's comments the messaging architecture
(data model of what constitutes a message etc) and the implementation
of that in particular protocols (choice of wire protocol,
argument value encoding etc) are to some extent orthogonal, though
of course some aspects of the latter will be restricted by the
choices made in the former. This suggests that decisions on the
details of the the particular protocols don't need to be based on
the intimate details of the architecture, though they will be
influenced by the general ideas.
I'd therefore like to see the architecture specification being
considered alongside any concrete changes we want to make to the
protocol that applications/hubs use. Doug has said that he doesn't
think drafting the architecture specification is too big a job,
so if it can be done quickly, great.
However, I don't think it's necessary that this must result
in a formal document at this stage (though it could do), as long
as someone is keeping an eye on the protocol-level decisions we
make to ensure that we're not doing anything which is going to
make compatibility with the (possibly yet-to-be-formalised) general
architecture.
To summarise: I am cautiously in favour of John's "twin track" approach, but I think that by making sure that the two tracks keep an eye on each other we can minimise additional work down the line, without a lot of additional work now.
To some extent this is reiterating what others have already said, but I wanted to make my take on it explicit in case anyone wants to disagree.
> In the interest of neutrality, my own distaste for the 'VOOM'
> name (sorry Rob), and borrowing from the wisdom of others, let's call
> this the Simple Application Messaging Protocol (SAMP). It may in fact
> be a reworked PLASTIC but the 'Simple' part of the name may help keep
> us focused and remind us that a more complete protocol will follow.
Simple like the S in SOAP? I quite like VO+M actually, but I'm can't get all that worked up about names one way or the other.
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/Received on 2007-04-27Z12:54:51