[MOBY-dev] RFC #1863 Error Handling in MOBY-S -- Vote Called

[Martin Senger]

> The vote has been called.  Voting members may vote by adding their YES 
> (accept)  or NO (do not accept) to the comments history  through Bugzilla
> 
> Voting ends Sept 26th
>
    I propose to extend the vote deadline to October 15th. Reasons are:

   1) The proposal (as available from Bugzilla) is still too complex, full
of explanaition, and it is not clear what is a discussion and what is a
proposal. I recommend that the authors take away most of the reasoning and
just state what is the new API. (The reasoning can come later back to the
documentation, if Frank, as a document-manager, decides so.)

   2) The proposal is in the format which is not readable for everyone
(for example, using OpenOffice mixes the tables on the first page, so I do
not understand what they mean and why they are there). Open source API
should use open documentation tools, as much as it can. The whole Biomoby
API/docs is, so far, written in non-proprietary document format, so I
suggest to continue with it.

   3) The error codes are still not explained enough. I suggest either
remove (some of) them, or document them better. Especially the client-side
errors are still obscure to me.

   4) The proposal is not clear how to integrate new XML tags in
serviceNotes with the current usage of serviceNotes. The current usage is
a free text: should this free text be expected before, or after the
exception code? Should it be there either exception tags or classic notes
text? This would be the only place in Biomoby API with XML-mixed element,
so it needs to be clarified, an example showing all possibilities would be
beneficial.

   5) The proposal should clearly suggest what (if anything) should be
removed from the current Biomoby API. I mean the fact that the current API
(even perhasp not literally, but surely by spirit) expects (allows) an
empty result in case of an error (e.g. an ID cannot be found in a target
database). Will this still be valid, or should serviceNotes be returned
instead?

   I already said that I liked the new proposal and I am going to support
it - but I want to introduce new things into Biomoby API as precisely as
we can. Therefore, I am not ready to vote yet. But just in case, my
suggestion described above, will not be accepted, and the vote deadline
announced by Mark will not be moved, I vote NO. (Sorry, I do not want to
do it on Bugzilla, because (a) I think that this NO is only temporary and
conditionally, and (b) I did not found any "history comments" there so I
would not know how to use Bugzilla for that.)

   Regards,
   Martin

-- 
Martin Senger
   email: martin.senger at gmail.com
   skype: martinsenger
consulting for:
   International Rice Research Institute
   Biometrics and Bioinformatics Unit
   DAPO BOX 7777, Metro Manila
   Philippines, phone: +63-2-580-5600 (ext.2324)