I think my take on this was that we probably ought to think less about
the store itself, and more about the protocol (although obviously the
store needs to implement this).
There are various different classes of error, and although the protocol
we've inherited is vaguely HTTP-like (in that 1xxx responses always
represent some kind of success, for example), it has really evolved
rather than been designed.
And of course, there are always going to be situations where you are
happy to ignore certain errors, and those aren't really grouped together
at all.
So I think the design ought to be along the following lines:
1. there is always a final status code, which is success or failure of
some description
2. there may be intervening content status codes (e.g. listing the
collection contents)
3. each command should have a small number of possible status
conditions.
At the moment, we have most of this in place already, it's more or less
a matter of cleaning stuff up. I also think that we ought to treat the
codes in two parts; the first being externally relevant and the second
being internally relevant (so each code is basically of the form XXYY,
and unless you're determining how something failed in the store, you
only care about the XX part).
As an example of how this might change these, take the CREATE command:
Results:
1. 1000 <collection guid> <create time> Created
2. 3010 Bad Arguments
3. 3014 Illegal Name
4. 3242 No store selected.
5. 4226 Collection Exists
6. 4227 GUID Exists
7. 5005 DB Library Error
(this is from the store protocol).
This could change to:
Results:
1. 10xx <collection guid> <create time> Created
2. 30xx Bad Arguments
3. 31xx Illegal Name
4. 32xx No store selected.
5. 40xx Collection Exists
6. 41xx GUID Exists
7. 50xx DB Library Error
Internally in the store, for a CREATE there may be a number of SQL
statements, so maybe the store would return 5003 if the third statement
failed. That would be useful information for developers debugging why a
command was failing when it ought to succeed, but simplifies the client
code because as far as it is concerned a 5001 error is exactly the same.
I would expect many of the same error codes would come out from other
commands: e.g. Bad Arguments is going to be common, so we would have to
look at whether or not we can make these codes consistent across the
entire store. It might be that one supplementary digit isn't enough and
that we actually need two.
Pat, any thoughts?
Alex.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
Bongo-devel mailing list
[email protected]
https://mail.gna.org/listinfo/bongo-devel
