Fwd: ISSUE: Naming of error object encoding

[Mark Taylor]

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 at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/