ISSUE: Naming of error object encoding

[Mike Fitzpatrick]

On Wed, Apr 30, 2008 at 5:57 AM, Thomas Boch <boch at newb6.u-strasbg.fr>
wrote:

> In section 3.8, the error object is currently made up of a map with the
> following keys : errortxt, usertxt, debugtxt and code.
>
> The naming of those keys could be improved by prefixing them with
> "error." or even with "samp.error."


I believe in an earlier draft it was explicitly stated that a message
Response was
not itself a Message (something I argued against).  The latest draft however
is a
little ambiguous on the matter, saying only that a  Response should be a
map
(which may be empty of sending back only an OK, but should contain those
keys
if an error).
     I would take things a step further and suggest that the error map that
is returned
BE a Message map containing a status Mtype (e.g. status.error) and where the
errortxt is a required param and the rest are optional.  In this case, a
successful
request could reply by setting only the 'success' argument and still have an
empty
map, but we could have a richer set of error returns that perhaps aren't all
fatal.
For example, a status.warning Mtype might still reply as a success but pass
back
a warning message, or a status.invalidParam could signal a specific
and universally understood error condition.

    My main objections to this simple set of keys are that 1) we allow only
an OK/FAIL
type of response, and 2) the 'errortxt' is allowed to be free-form (okay if
all you want
to do it pop up a dialog,  not okay  if an  app needs to parse the message
for information).

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