On Thu, 1 May 2008, Mike Fitzpatrick wrote:
>> However, I think it would be unhelpful to label this status as an MType,
>> since such statuses only make sense as something returned from a Message
>> rather than sent unprovoked. Also, if the status in the reply to a
>> Message is an MType, it suggests that any MType is allowed in that slot.
>> Does this mean you can only receive a response from a message if you happen
>> to be subscribed to the MType that it has when it is returned? Given that
>> an MType is documented to require some returned
>> value, does it mean that you have to reply to the response?
>> What are you supposed to do if you get a "spectrum.load" MType in the
>> response to a message with a "get.param" MType? If you say that the only
>> MTypes which can be allowed in those slots
>> are "status.*" ones, I don't see the advantage of these being MTypes
>> rather than just some separate controlled vocabulary.
>
> Applications that engage in free-association as you describe deserve
> what they get.
but wouldn't it be better to design a message system in which that sort of misbehaviour is not permitted?
> get. The receiveResponse() method could simply ignore anything other than
> a status.*
> mtype if it wants, I'm only suggest a Response can share the Message format,
> not that
> clients handle it in the same way.
> A more realistic example would be:
>
> - Client A has a FITS MEF file with an image and its catalog
> - Client B subscribes to 'image.display' but not 'image.display.extnum'
> that would let
> A specify which extension had the image
> - Client C subscribes to 'table.load' but not 'table.load.extnum' that
> would let
> A specify which extension had the table
> - Both subscribe to 'file.load' indicating they would do something
> reasonable with a file
> - A sends both a 'file.load' and the MEF filename; B replies with an OK
> success and
> and MType of 'image.event.load' to indicate it found and displayed the
> image extn,
> and replies with 'table.event.load' to say it found the catalog
> extension.
This story as told sounds like it makes sense. My problem with it is that it allows too much freedom in the response. While this may sound like a good thing (it gives you lots of message pattern possibilities), it becomes a problem when you want to write application code which sends a message and deals with the response.
If the response to a file.load message is known just to be a success/failure flag (with additional information about the kind of failure it is) I can write code like:
send file.load message
get the response
if (response is success)
inform the user of success
perhaps do something with returned values in the reply object
else
get the error text, code etc from the reply object
display the error text, code etc to the user
If the response is an MType, my code looks like
send file.load message
get the response
switch (response.Mtype)
case status.ok:
inform the user of success
case status.error:
get the error text, code etc (message params) from the reply object
display the error text, code etc to the user
case file.event.load:
inform the user that a file was successfully loaded
case image.event.load:
inform the user that an image was successfully loaded
case table.event.load:
inform the user that a table was successfully loaded
default:
tell the user that something happened, but I don't know what?
Yes when this works it allows more detailed information to get back to the user. On the downside it can be considerably more effort to write. The real problem however is that the sender has to second guess the intentions of the recipient in terms of what MTypes they are likely to respond with. That can work if the developers of the two applications can get together and agree about it, but in a situation where you don't know the identity of the recipient, it is effectively an artificial intelligence job to make sense of a result which can have such a wide (and indeed open) range of values. The way that MType subscription works, normally you can be sure of only receiving messages with MTypes which you have explicitly said you know what to do with, so you don't need to worry about unknown MTypes. But if the MType arrives in a response, it might easily be one you are not subscribed to and maybe even have never heard of before.
As far as I can see the only way of making it feasible to write application code in which the response is formally allowed to be any MType, is to document for each (send) MType what MTypes it is allowed, or at least expected, to reply with.
If you're with me this far (and I'm not counting any chickens) maybe the best thing would be to return to the MType vocabulary and fill it out a bit. If you can write up a few MType descriptions in detail, including what MTypes they are permitted/expected to reply with, I'd have a better idea of how you envisage this working in practice. I am still sceptical that this is a good idea, but perhaps it's just because I haven't seen how it would work in detail.
> The litmus test for features should be whether our final design provides
> all of
> the PLASTIC functionality required in v1.0, not whether a feature is deemed
> unnecessary
> in the PLASTIC usage model. I'm sorry for casting your thoughts in such a
> simple
> manner, I know that's not the case or your intent, but I'm feeling like
> generalizations
> that do no apparent harm to the spec have been met with resistance simply
> because
> there seems to be no immediate use for it.
> If you really think about it: Does a Response being a Message and
> having an MType
> do any harm to what you need? Does it open possibilities for things you
> haven't considered,
> even if those things are too fanciful to ever be implemented?
Yes it does do harm to what I need: as I've tried to illustrate above it's much harder to write application code if the response can be anything from an open-ended vocabulary than if it is known to be either success (plus additional information in a form dictated by the original message MType) or failure (plus defined additional information common to all errors).
To answer your broader point: I plead guilty to resisting generalizations which I can't see a use for, if they add significant complication to the protocol design or significantly increase the burden on client developers. I do want to leave the door open for things I haven't thought of (though I think we make too many concessions to things which are too fanciful to ever be implemented at our peril), but I think in terms of the message and response payloads this is done better by allowing the possibility of additional entries in the response maps than by forcing the response to be an MType.
Mark
-- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2008-05-02Z13:34:48