> 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 socketbased 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 Received on 2007-04-07Z12:13:05