> > 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.*'
>
> This sounds like something which might be better done with the naming
> service which the "hub" already provides. That is, a display service
> registers with the naming service (hub), usually at connect time.
> Later, and app which needs such a service can merely query the hub
> naming service directly and efficiently. A general broadcast is really
> only needed in the absence of a naming service.
But again it's in the interpretation of 'display.*' as to what happens, unless we require that apps must register only with complete mtypes (in which case we can ignore the wildcard issue altogether). I'd rather stay away from explicitly stating types since I can think of a number of examples where I might want to subscribe to the display.* messages but not necessarily act on all of them. Registering with a e.g. display.url capability at least implies I will do something with that message, but (like a lot of people on this thread) what if I'd rather just lurk until something interesting comes along?
> > I had a particular case in mind of calling an IRAF task. So the messages
> >
> > mtype=set.param args="imfunc.input foo.fits"
> > mtype=set.param args="imfunc.output bar.fits"
> > mtype=set.param args="imfunc.function sqrt"
> > mtype=exec.task args="imfunc"
>
> I suppose one could do this, but wouldn't it be better done as a single
> REQUEST with arguments? e.g., mtype=iraf.execTask args={{imfunc},{foo},...}
> Better to avoid assuming state unless you have to. What you have here
> would probably fail in a concurrent situation.
This is similar to John's earlier suggestion and something I could live with. I would prefer though that we not resort to a iraf.* class unless we really need to, i.e. if we agree that the argument string to an exec.task message is assumed to be meaningful to the recipient it doesn't matter what form the command takes or that it's IRAF, IDL, or anything else with an interpreter (Aladin and Mirage have scripting, could they use this?). We might need other similar messages to do things like load a config file or plug-in, launch a command or a new instance of the app, etc.
I was aiming for an mtype scheme where messages had some kind of predictable meaning, but maybe one that varied by context. For example, set.param to set a task parameter in the CL is perfectly logical, but a set.param message to the Hub to set a timeout for synchronous msgs isnt' quite the same kind of param in the same kind of environment, but is just as logical given the context. Similarly, responding to a display.* message means I'll give it my best effort to do something logical. The Apps WG then should find agreement on a (small) vocabulary so there is predictable functionality to a message, maybe it's the best you can do with the apps available until you install a different app that handles it better, but it lets the developers decide what is the best way to implement a given mtype based on their app.
-Mike Received on 2007-04-10Z23:00:56