Apps Messaging - Semantics of a Message

[Mike Fitzpatrick]

> Could you explain a little what you mean by implementation here?  Do you
mean
> the implementation of a hub?

Actually I mean the delivery method.  For example, in RPC we might have a
perform() method that requires each attribute as an argument, in a socket-
based string message these might be keyword-value pairs where missing
attributes aren't required.  In a different system the idea of the
sender might not be needed at all.


> The NOTIFY/REPLY/REQUEST distinction is useful for us as mtype authors to
> understand new mtypes that we're trying to write, and learn (patterns?)
from
> existing mtypes.  Do you see this as something that machines will also
need
> to know?  e.g. a message has a parameter giving its type?  Surely if an
> application understands a message, it will know whether or not a response
is
> needed, and what form that response will take?

        This is an artificial distinction for discussion:  A REPLY will
usually be just a status.reply mtype, otherwise the spec might categorize
REQUEST as some set of messages that SHOULD issue a reply, and NOTIFY as
those that explicitly won't reply.  Apps are always free to ignore expected
replies, or charge on if they never get a reply (hence the idea of asynch
messaging)

>     Instead, the mtype is meant to create a "rough concept" of a
>     message such as "display an image";
>
> I'd go further.  As Alasdair has already mentioned, we've started to move
> towards an even more general model where the sender just says "here is an
> image: do something with it"...or "here's a couple of columns from that
table
> I sent you earlier".

All I can say is that a "here's an image, do something' message to a
msg-enabled IRAF is just asking for trouble.  What you describe is a
data-sharing interface and not messaging where the messages have any real
meaning or predictability for the user.  I would also argue that appending
the ivorns is just a verbose variant of the 'root.detail' mtype idea and
an example why specificity in messages is needed in the real world.

>     Likewise, any two client apps are still free to use a mutually agreed
>     private set of messages outside of the mtype vocabulary and exchange
them
>     using the same underlying system.  If we were to tag the message as
>     something like "generic;display.URL' an app MAY choose to provide only
>     the functionality implied by the spec for that message (e.g. not save
a
>     result reference), otherwise it may always reply with a reference that
>     a sender might ignore.
>
> Like Alasdair, I feel this is essential.  I see our role as being the
means
> through which the community can standardize and record commonly-used
> messages, not as a rigidly controlling body.  If someone wants to go off
and
> build a better loadTable mtype, then they're welcome to.  They'll probably
> get better interop if they work with us though.
> Not only can we work to create the mtypes to satisfy the current common
use
> cases, we can also (hopefully) put the experience to use in suggesting
(not
> mandating) good patterns and best practice.

        Interoperability is achieved when a message does "the right thing"
regardless of the receiver.  If you have a better votable viewer the user
is free to start it instead of mine, but a load.table should behave
similarly.
If that user knows you have a specific ability, he should be free to send a
message that exploits your feature and might be ignored by my app.  The
controlled vocabulary should guide developers to use common messages for
common usage, but I should only need to "work with you" when I need to do
something peculiar to your app.  A loadTable should still work regardless of
whether the user has your or my app running as the receiver.


> >       sender      The <appName> of sender application.  The Hub
> >                   will supply this attribute to the receiving
application.
> >                             :
> Sorry Mike - I don't quite understand this.


All I meant is that the sender of a message only needs to be known to the
Hub and MAY be included as part of the message delivered to a recipient.'
In the PLASTIC API I can apparently get the id of Aladin and send a
message to TOPCAT using that id, is there any advantage to this or any
reason I need to know  my own id to send a message?  Can't the Hub fill
this in for me?


> We need to decide whether apps are identified by a session-unique,
> hub-assigned key, or a (possibly non-unique) application-assigned name.
I'd
> argue for the former as less likely to get us into trouble.  I do see the
> benefits of your worker1 & worker2 use case below though.

In a session-assigned id how can I know a particular instance is what I
need?  For example, in a small pipeline to process MEF files I might create
named worker1 thru workerN tasks to handle each extension and want to send
my workers a message (but not anything else that claims to handle that
message).  Unless a worker can register with a name like 'worker1' I can
recognize, how do I know the extension I assigned it might have failed if
the appName is something like 'worker<pid>' that has no meaning to me?
I suppose a REPLY could help but is complicated.


> > Likewise, any two client apps are still free to use a mutually agreed
> > private set of messages outside of the mtype vocabulary and exchange
them
> > using the same underlying system.
> >                   :
>
> Like Alasdair, I feel this is essential.  I see our role as being the
means
> through which the community can standardize and record commonly-used
> messages, not as a rigidly controlling body.  If someone wants to go off
> and
> build a better loadTable mtype, then they're welcome to.  They'll probably
> get better interop if they work with us though.
> Not only can we work to create the mtypes to satisfy the current common
use
> cases, we can also (hopefully) put the experience to use in suggesting
(not
> mandating) good patterns and best practice.

The 'unrestricted' vocabulary is meant to allow for developers to exploit
certain features in an app they know about.  More generally, the controlled
vocabulary is meant to provide predicability that a recommended mtype will
do a certain thing (more or less) that the user wants.  Interoperability
is when the same message can be used regardless of the target app, but
if my votable viewer is better than yours a user can fire it up instead
and Al's client won't need to be changed.  OTOH, if yours does something
unique Al's client can send the private message and if mine is running
nothing happens.  I see the controlled words as a way to guide users to
use the common mtypes where possible, and the free words as a way to
use the system for delivery but still make use of the creativity of a
developer in an app that might do something completely unpredicted.

> >     sender      The <appName> of sender application.  The Hub will
supply
> >                 this attribute to the receiving application.
> >                                          :
>
> Sorry Mike - I don't quite understand this.

All I meant is that the only time an app should need to identify itself
is when it first connects, not as part of sending a message since the Hub
would already know who was sending and could fill this in.  In the PLASTIC
API I can apparently get the plasticID for Aladin and send a message to
TOPCAT using that ID from a 3rd party app -- is there some advantage to
this or any reason why I need to even know my own id when sending a message?

> We need to decide whether apps are identified by a session-unique,
> hub-assigned key, or a (possibly non-unique) application-assigned name.
I'd
> argue for the former as less likely to get us into trouble.
> I do see the benefits of your worker1 & worker2 use case below though.

Consider the case of a small pipeline system to process MEFs:  I might
want to start the same worker process multiple times to handle each
extension in parallel and send a message only to my workers rather than
to everyone who can handle that type of message.  They might connect as
worker1 and worker2 so I can differentiate the error message they send.
In app-assigned naming this is easy and up to the clients, otherwise we'd
need a policy that all 'worker' apps get a message or some way of choosing
which instance.  We would also lose any meaning the "main" application
may assign to each worker, e.g. I know I started worker1 and worker2 and
what I told them to do, an error from the session-unique 'worker<pid>"
ID wouldn't tell me which extension wasn't processed.

> Perhaps I'm missing something here, but isn't this implicit in the mtype
of
> the message being sent?  That is, if an application has registered its
> interest in mtypes foo.*.bar it will receive messages foo.donkey.bar,
> foo.duck.bar etc.

Right, but this is just the mtype pattern matching in action.  Perhaps an
app registers broadly with 'display.*', it would get the message but
silently ignore a 'display.URL' if it couldn't handle it.


> Why not just send the attributes anyway and the recipient can ignore them?

> Simpler than adding an operation for the recipient to get the attribute
> after the message has been delivered, or do you have some other use in
mind
> that I don't see?

See my first comment about the implementation.  I'm all for sending
everything but it adds extra msg processing to the app where it might
not be needed.


-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/apps/attachments/20070407/9d9ba227/attachment.html>