Apps Messaging - Semantics of a Message

[Doug Tody]

Hi Guys -

The main problem here is that some of us have a very narrow application
of messaging in mind, and are happy with that, whereas others need
to do other things with messaging, which PLASTIC does not support.
It is possible to provide something simple, and very similar to the
current PLASTIC facility, on top of a somewhat more general messaging
infrastructure, but only if we are willing to go to the effort.
This more general approach is required to be able to support the full
range of messaging capabilities required for typical astronomical
desktop applications.  PLASTIC alone is not enough.

Those of us who need the more general approach for our applications
would be happy to do the work to specify this, and a good start has
already been made.  Current implementations (of all sorts, not just
those which use PLASTIC) would probably need some changes; as I noted
earlier, probably these are simple to make though, so long as the
architecture as seen by the application is largely the same.

The alternative is a more limited facility which cannot support the full
range of applications, which means that we still have to do this work
eventually anyway, and will probably end up with multiple messaging
facilities which do not interoperate.

> I think the success of PLASTIC was driven by the 
> fact that, at least from the application developers perspective, it was 
> amazingly simple to implement and get you application talking to other 
> people's applications without having to get the other people in question to 
> do anything at all.

This can be achieved in any case, by continuing to provide a simple
interface, with similar semantics, for this class of application.

 	- Doug


On Sun, 15 Apr 2007, Alasdair Allan wrote:

> Mark Taylor wrote:
>> However, we're probably not going to progress further on this by
>> continuing to argue about it.   Some people in the debate are more
>> concerned with how the data model underlying messaging is formulated
>> (with a view to permitting various different implementation profiles
>> as needs arise in the future), and others are more focussed on
>> sorting out the nuts and bolts of what an application has to do
>> in order to participate in a messaging...
>
> I'd agree with Mark here, we're obviously arguing from very different 
> perspectives. I'm far more interested in getting something simple that will 
> work tomorrow, and can if needed be extended next week, that some beautifully 
> top-down designed architecture that won't arrive till next year.
>
>> *If* we go down the route of revolution (scrapping PLASTIC as it stands
>> and replacing it with something which can do similar things but which
>> may have advantages such as more flexibility and securer theoretical
>> underpinnings)
>
> I'll put my hand in the air now to say that I think this would be a bad 
> thing. There is a bunch of stuff wrong with PLASTIC, but none of that is bad 
> enough to throw it away. I think the success of PLASTIC was driven by the 
> fact that, at least from the application developers perspective, it was 
> amazingly simple to implement and get you application talking to other 
> people's applications without having to get the other people in question to 
> do anything at all. Even poorly behaving PLASTIC applications (some behave 
> deliberately poorly for various reasons, but leaving those aside) at least 
> present some level of functionality to the user.
>
>> rather than evolution (incremental modifications of
>> the existing PLASTIC standard to allow it to do new things where new
>> capabilities are required), then I am happy that this is done along
>> lines similar to those that Mike and Doug are advocating, although
>> there are still matters of detail to address.
>
> Agreed.
>
> Al.
>