On 7 Apr 2007, at 20:39, Mike Fitzpatrick wrote:
>> > 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.
>
> I disagree, what possible use is "here's a table" as a message
> other than to generate a "so what" reply? A response to a
> get.datatype
> message might encode the answer this way but the mtype of the reply
> will
> still be status.reply.
Hi Mike,
"here's a table" isn't the whole message type, it's just the bit that needs to be specified by us to ensure interoperability. Individual apps can then refine that message type further to advertise what they would do with a such a table.
>
>> 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.
>
> I strongly disagree here: In this scheme I now need to know
> that
> the combined mtype represents a data type and an action you want me
> to do
> on that data. What I do would be different if it were
> table.votable.file
> and if doSomethingCool() didn't already know about URLs I'd have to
> add
> that as extra complexity.
Well yes, surely you need to know the data type, how to get at the
data, and what to do with it, before you can take any action? These
don't all have to be in the mtype...you could pass the datatype as a
parameter of the message, but the advantage of it being in the mtype
is that the receiving application is advertising in advance what data
types (and retrieval methods) it can deal with.
I'm not sure that we'd need a table.votable.file if we had a
votable.votable.url, but just supposing we do, then yes, the
receiving application would do something different on receipt of
table.votable.url#doSomethingCool
and
table.votable.file#doSomethingCool
(in this case the messages probably do the same thing as far as the user is concerned...the only difference is how the data gets from A to B, so we might want to adopt some convention that allows us to reflect this in UIs...but that's not a detail to worry about at this stage).
> For example, when I first listed the set.param and exec.task
> mtypes
> 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"
>
> could set the individual parameters and invoke the task (in IRAF you
> can set a parameter as "<task>.<param>=<value>" on the command line,
> I realize imfunc.input looks like an mtype but it means the 'input'
> param of the 'imfunc' task). This scheme works to call almost any
> task
> the same way. If an image were a URL I could download it to a file
> and
> the above stays the same, but implementing 'image.fits.url#imfunc'
> means
> I need separate methods for each task I might call (rather than a
> generic
> callTask()),and things just overall get messy. I'd point out that
> here
> we have 2 mtypes that let you access literally hundreds of tasks!!
I'm afraid I don't know what this IRAF task does, but superficially this looks like a great example of the sort of message type that is so application-specific that it's not the apps-group's job to standardise it, but would be best left to the IRAF authors. However, if it is generic enough that there are likely to be several applications providing this sort of functionality then the apps group can define the following mtype [which you can delimit into atoms according to taste]
processFitsImage, takes a URI of the input image, returns a URI of the output image
and IRAF will declare that it understands
processFitsImage#sqrt
processFitsImage#addSepiaTone
....
Should the industrious IRAF team add another function then all they need to do is declare a new #fragment, and all of IRAF's clients will magically know about the new feature. No recompilation required, and no work from us. Now, many of these functions will probably require more than just the input file...they probably will need some parameters as well. No problem: we define processFitsImage to take an optional struct of parameters.
So
processFitsImage#rotate
will be accompanied by parameters (url=file loc, options=[angle=90])
It's not foolproof - the option list will be specific to each IRAF function, and the user of the sending application will have to read IRAF's docs to get the valid parameters.
*Anyway*, this discussion is probably going a bit off-topic - should we postpone this till we've got the higher-level decisions sorted out? I'm sure there are plenty of folks currently on long Easter breaks who will want to contribute.
>
>
>> 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.
>
> It shouldn't be too bad given that most environments/languages
> have some sort of regular expression capability. Note also that the
> matching is done only in the Hub and not the client, i.e.the Hub
> matches
> 'display.URL' with apps registered using 'display.*', however the
> delivered message contains the full mtype value so it's just a matter
> of parsing a dot-delimited string and some string compares (easy even
> in Fortran).
>
I wonder if we're not quite on the same wavelength here. I see clients as declaring to the Hub the message types that they support, and this information being available to other clients to do things like populate menus appropriately. If client A declares that it supports "table.*.url", then client B will need to parse this expression to know that if it has a votable then it can offer the user a "send this table to client A" button. While dealing with "table.*.url" isn't too bad, dealing with "table\.[Ff][Ii][Tt][Ss]| VOTABLE*\.inline|url" could be a challenge!
(Of course, I also see the hub using the expression to filter messages.)
John Received on 2007-04-09Z14:40:21