Tony Linde wrote:
> Thanks all. I agree that, as it stands, plastic is not supposed to
> be any sort of message queuing system: if it is just passing
> messages around apps on a desktop, the user can plainly see if
> anything has happened and click the button again if the message
> didn't arrive.
Yup.
> It may be that Al's hack to route messages between different
> machines could stray into Doug's distributed apps scenario
Yes and no. Nothing bad happens if the data doesn't get to the user in my case, basically this is the back end intelligent agent doing the user's science sending an asynchronous update to the UI the astronomer uses to find out what's going on with their observing program. If if doesn't arrive, it doesn't matter. The user has more secure ways of requesting this information, and plenty of buttons and widgets to click on to do so.
> and agree with Al that it ought not to be part of any initial
> standard.
I'd tend to agree, be we should try and leave a hole where it should go if we want to drop it in there later.
>> PLASTIC did right was leaving the messages alone...
>
> I think you do need some standard messages but agree that the
> messages need to be extendable, much as we did with the registry
> types.
Agreed. There has to be some standard messages that deal with the basic infrastructure negotiations (application discovery for instance). Some client side messages are also obvious, loadImageFromURL for instance was a no brainer. But we do need to leave it extensible, and we need to be able to extend it in an ad-hoc manner. One of the good things, in my opinion, about the current PLASTIC Hub implementation is that it doesn't care about messages. I can make one up and use it between my own applications with impunity, in fact I have done so on several occasions. I can publish this and tell people I'm using it, and if other people like it they can implement it. PLASTIC is very much a ground-up standard rather than a top-down design (at least to a certain extent) and that is one of its strengths.
Al. Received on 2007-02-08Z14:26:15