Apps Messaging - Semantics of a Message

[Mike Fitzpatrick]

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