Apps Messaging - Semantics of a Message

[John Taylor]

On 4/6/07, Alasdair Allan <aa at astro.ex.ac.uk> wrote:
>
>
> > as well as apps that wish to monitor the message traffic.
>
> ...although I think you might get some objections to this, this has
> various security implications we might need to have a serious think
> about. If we direct a message (via the hub) to a specific
> application, should other applications be able to intercept it? If
> you broadcast the message then the user (or at least the application,
> the user probably won't have a clue as to what's actually happening
> under the hood, and nor should they) is expecting it to go to
> everything, but a directed message. That's a bit controversial...?


I think if we allow this (and it is useful on occasion), then it's going to
have to be something that needs to be explicitly enabled on a Hub by the
user.  Not all hubs will necessarily support it.

 []

>
> > free to use an argument list peculiar to the target app and perhaps
> > expect
> > a reference of some kind to the downloaded image for later processing.
>
> That complicates the specification a lot (well, at least for heavily
> typed languages). Those of us living in the 21st century and using
> loosely typed languages probably don't care, but I can see the Java
> guys tearing their hair out at this point...


Nah - we've got Object[] !


 []

>
> >               knowing what the Hub assigns as some ID.  Just as there
> >               may be multiple identical instances of a Recipient, a
> >               Sender should be likewise free from a specific instance
> >               defined by a Hub ID.
>
> Okay, seems reasonable. You are sort of assuming that application
> names are unique(ish), but I guess that's sort of okay. If we're
> supporting desktop-2-desktop messaging then we can posisbly work
> around this in other ways.


Even if we were to prefer the session-unique hub-generated keys approach,
we'd still have problems when we go desktop2desktop.  Nothing we can't work
around though.



>     recipient The recipient of the message.  This is a String value
> >               supplied by a sending applicaton that may be one of the
> >               reserved words:
> >
> >               Hub         Message is intended for the Hub only and
> >                           will not be forwarded to other apps.  May
> >                           only be used with SET and GET class messages.
> >                           (Message classes are discussed below).
> >
> >               Any         Sender wishes to broadcast to all clients
> >                           currently connected.  These are typically
> >                           used only with STATUS and EVENT class msgs.
> >                           Applications that cannot, or choose not to,
> >                           handle the message is free to ignore it
> without
> >                           posting a reply notification.
> >
> >               Additionally, the recipient may be one of:
> >
> >               <DEFANGED_appName>   Indicating the message should be sent
> to all
> >                           clients with this <DEFANGED_appName>.
> >
> >               <pattern>   Indicating the message should be sent to all
> >                           clients that have registered a capability to
> >                           handle messages matching the specified
> >                           pattern.  The use of '*' as a <pattern> is
> >                           a special case of the reserved word 'Any'
> >
> >               In these last two cases, the Hub will first attempt to
> >               match based on the <DEFANGED_appName> before
> <pattern>.  Wildcards
> >               are permitted in the <DEFANGED_appName> to allow sending
> to a subset
> >               of apps (e.g. sending to "worker*" will deliver the
> message
> >               to identical instances of both the 'worker1' and 'worker2'
> >               apps as well as multiple instances of an app that
> connected
> >               simply using the name 'worker').
>
> Fairly uncontroversial I think...
>
> >     msgid     A unique id assigned to each message by the Hub and
> included
> >               as a message attribute for the RECEIVEd message.  This
> >               value is returned to the sender as a response to the SEND
> >               method, the msgid will remain the same in a REPLY method
> >               message so the sender can identify the originating
> message.
>
> So long as we're talking about a per-session uniqueness rather than a
> uniqueness for all time then I'm okay with this concept.


That's what I'd assumed.


If we get to
> []
> > and the number of apps involved in any one exchange is separate
> > from the
> > underlying transport.
>
> Okay, although I'm worried that this could start to needlessly
> complicate things, I'm really keen to maintain "simple" as the
> overriding definition of this specification. It need not be all
> things to all men.


Yes, I think we definitely want simple.


> Message Types
> > ----------------------
>
> I dealt with this in my other email...
>
> > Rigorous Message Types
> > ----------------------
> >
> >       The PLASTIC implementation of messages is based on the idea that a
> > message type is an 'ivorn'.  The primary argument for this approach
> > is that
> > the Registry can be used as a central repository for a description
> > of the
> > message, however there are several problems in a generalized system:
> >
> >     - The message ivorn is based on an ad-hoc agreement between
> > developers
> >       of specific apps and does not specify the semantics of what that
> >       message might mean to later app developers.
> >     - While an ivorn may be searchable in a registry, the
> > descripion of that
> >       ivorn isn't generally machine-parsable.  This means an app can't
> >       effectively resolve an ivorn at runtime to determine a needed
> >       capability, and even a search for capabilities registered for a
> >       specific app would require a network connection for the
> > 'system' to
> >       operate at all.  Apps should be able to make requests for
> > capabilities
> >       without an available Registry using only the locally running
> > processes
> >       (or tasks that can be invoked based on a requested message).
> >     - IVORNs are more complicated to parse than UCD schemes and so the
> >       filtering of messages is also more complicated in an app.
> >
> > That said, the current PLASTIC messages appear to have the same
> > idea of a
> > message hierarchy (e.g. by including "/fits" or "/table" in the
> > path) even
> > if these messages are implicitly tied to a specific implementation.
>
> We've sort of decided that this might have been a mistake, at least
> in some cases. For instance the pointAtCoords message really should
> have been handleCoords or something like that, leaving the decision
> what to do with the coordinates themselves up to the application.


Agreed.  Some of the plastic messages have inappropriate names.  showObjects
is another one, but that's a legacy of having borrowed ideas from the Aladin
authors - at the time all we intended this message to do was highlight
points in Aladin.

J



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