> > MESSAGEs can be described generally as being a NOTIFY, a REPLY,
> > or a REQUEST message. NOTIFY messages are purely informational and
> > require
> > no response or confirmation of delivery. A REQUEST message is one that
>
> I think that labelling messages as NOTIFY, REPLY, REQUEST is a good
> idea as it captures the kind of job it's trying to do; this
> message classification can stand as boilerplate which will reduce
> the amount of additional documentation required per mtype.
There is another message type, OFFER, which I left out originally since I'd thought it might only be useful as a means to offer some service but couldn't really think of a way the sender might request the capability. I'll bring it up now in light of some of the recent discussions.
One example being discussed is the idea of a 'display.*' mtype of a message, I saw the '*' strictly as a filtering mechanism but others think of it in terms of a wildcard expansion to all possible values. One place where an OFFER might come into play is with the "I need a display task" offer message that can be broadcast using the 'display.*' mtype, receivers could then reply with a specific capability offer such as 'display.url' and 'display.fits' and the sender can decide which app to use or simply build a menu of the responses. The down- side here is that the pattern matching moves to the client, however interfaces like VOClient could do this to hide it from Fortran code and an app doesn't need to know the message was even handled.
In another case a client that creates an object can send a REPLY to the original load/process command but also broadcast an OFFER of the refID to apps that may want to keep track of what's available and where. This might be a way to get the refID out of the message content explicitly but still retain the functionality.
In a third example, my hypothetical MEF pipeline might have the 'worker' tasks sending OFFER message
> while spoofing is a problem (addressed in other messages today) I think
> it does make sense to identify different instances of the same application
> as different items, so I'd say a unique (per session) application ID
> of some sort would be a good thing.
I don't necessarily disagree with this. However, and I'm mixing message content and implementation details here, I don't see why this has to be explicit in the message interface. Connecting to the Hub might indeed generate an appID that needs to be tagged with each send() request, but can't it remain private in the interface? My argument is just that it becomes something the app needs to carry around in user space and I'm not seeing the advantage to this.
-Mike Received on 2007-04-10Z19:23:04