Fwd: Apps Messaging - Semantics of a Message

[John Taylor]

Sorry - forgot to reply-all.

---------- Forwarded message ----------
From: John Taylor <jontayler at gmail.com>
Date: Apr 7, 2007 2:53 PM
Subject: Re: Apps Messaging - Semantics of a Message
To: Mike Fitzpatrick <mjfitzpatrick at gmail.com>



On 4/7/07, Mike Fitzpatrick <mjfitzpatrick at gmail.com> wrote:
>
> > 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.


Ah - I'm with you.  That makes sense.


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


I think what we're debating is what exactly we need to mandate in this group
for the messaging to work in the real world and yet still be flexible.
Forget the ivorns for a moment - the exact format of the message types
doesn't matter.  What I'm arguing is that we (this group) might define an
mtype such as:
table.votable.url as representing a general "here's a table of format
votable available from a URL".   This contains all the information that a
sender needs to send the table, and all the information that the receiver
needs to receive it.  What actually happens to the table isn't any of our
business. So then IRAF can come along and declare that it understands the
following mtypes:

table.votable.url#load
table.votable.url#doSomethingCool.

The part that we defined specifies everything that the applications need in
order to communicate: there is a table; it's in VOTable format; it's given
by a URL and here are the parameters.  The part that the IRAF author defines
adds the detail needed for the sending application to tell its user what to
expect if such a message is sent.  We don't need to define this in the apps
group: every application will be different.  These "fragments" will change
much more rapidly than the apps group-defined part - and why not? nothing
will break if the do.  Indeed, an application could even create new
fragments "on the fly" as circumstances change.

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


I think I agree with that.  We will probably still see developers inventing
new messages that aren't necessarily specific to their apps.  We shouldn't
try to prevent this (how could we, anyway?), but we'd hope that they would
develop their ideas through this forum so that others can contribute.


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


I guess it would depend on the "wire protocol".  In xml-rpc, for example,
it's difficult to see how the hub could know who is sending the message
unless the sender includes its ID.  It is often useful for the recipient to
know the sender.  For a trivial example, my TabView application uses it to
display  appropriate logos on the tables it receives.  At the moment Plastic
allows one application to spoof another.  I can't think of any reasons why
this is a good thing, but it's easily stopped (see my email on the messaging
protocol).



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


There are operations on the hub that allow a client to get the ids of all
the registered apps, and for each id get the name of the app (as specified
by the app at registration).  It would be straightforward to filter the ids
by name to get the ones you want.  If this proved to be a common usecase we
could provide an operation on the hub to do it, but it's not too difficult
to do on the client.
In Plastic, the only metadata that the hub stores about an application
(apart from its id) is its name.  All the rest (ivorn, logo, description...)
it obtained by sending the application a message.  I think this is a bit of
a wrinkle.


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


Yes, or it could display an error dialog.  If it claimed to support
loadtable.*.url and received loadtable.fits.url without understanding FITS,
it probably ought to tell the user why it hasn't loaded the table.  This
behaviour is therefore application and mtype-dependent.
Better still, perhaps it should register with a pattern such that it doesn't
get messages it can't understand!

My feeling is that the pattern matching could be useful, but will also
complicate things for the client (particularly if we allow patters more
complicated than "*"), so we'll probably need more debate on this.  As I
said in my initial response, I think the UCD concept for building up mtypes
is a good one even without the pattern matching.


> 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/a775a33e/attachment.html>