ISSUE: Naming of error object encoding

[Mike Fitzpatrick]

Mark,


In the Nomenclature section (2.1) it says
>
>   "In the terminology of this document, a Response is not itself a
>    Message."
>

   Well, that certainly looks like an easy-enough sentence to change. 8-)



> I'm not necessarily against supplying a status in message responses;
> a "status" (or "error.status" or "samp.error.status" or whatever)
> key could be added to those suggested above and could take values
> such as "error", "warning" and others from a well-known vocabulary
> which we supply, possibly allowing users to extend it for their own
> purposes.


    The problem here is that we're then defining a separate vocabulary for a
Response
than we are for Message MTypes.  I'm already worried that we're confusing
things
to have a 'samp.hub.method' in the XML-RPC profile, a 'samp.secret' in the
lockfile
metadata, a 'file.load' as a MType and now a 'status.warning' in a Response
status
keyword.  The 'word.word' syntax is too overloaded with meaning.
    If we require that the Response 'status' element have the same meaning
as the
'status' MType, why not just the make it an MType?


> 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.   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.

There are better ways to do this using the Notify as a separate event, but
since we allow
apps to make up their own MTypes some clever developers may agree on a
pattern that
could make realistic use of MTypes in both the call/response.



> as I said above, by all means propose some key for a non-free-form,
> parsable value, and values it can take, to go along with the others proposed
> for the error response map.
>

    As i say above, any such key would be a separate vocabulary and further
overload
the 'word.word' syntax we use for MTypes, metadata namespaces, method names,
.....
Having a Response be a Message means we can use the Mtype for the status,
and
the map would depend on the mtype for whether errortxt or some other key was

expected.  Things like a 'codetxt' key could be optional, but regardless
we'd have a
documented way to present errors of many kinds that all apps would use to
interoperate.


I think you're suggesting that you might want to return whatever
> is the return value from the message (as determined by the MType)
> but also have the ability to flag a Warning or some other non-OK
> status rather than assume that if a value is returned then the status must
> be OK.


    What I'm arguing is that we have no *consistent* way to transmit a
warning:
One app might set success=1 but since the Response is empty fill it with
the map containing an 'errortxt' anyway, another app might set success=0
to convey the warning but would have filled the request (in some way)
anyway,
and neither app has any reliable way to catch an error to see whether it can
be
recovered somehow.


However, I'd argue against it as providing an unnecesary feature.
> Procedure calls in most modern programming languages get by with
> call semantics in which either the thing succeeds (and you can look at the
> return value to find out the result) or it fails (and throws and exception
> which you can examine to find out what
> went wrong); no fuzzy third way is provided for.  This is the model I have
> in mind for the synch and asynch call/response patterns, and I don't think
> that we need anything with more
> flexibility than that.


     We're not designing a language, we're designing a system that has to
provide
the same exception handling as we would expect from a modern language.  A
simple
free-form 'errortxt' is not acceptable, a separate vocabulary for a <status>
key
is unnecessary, and I can easily think of reasons why we'd need more
flexibility
beyond the simple PLASTIC usage model in later versions of SAMP.

    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?



Cheers,
-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ivoa.cacr.caltech.edu/pipermail/apps-samp/attachments/20080501/e7403601/attachment-0001.html>