[MOBY-dev] [moby] Re: Large amounts of requests from always the same IPaddress - 137.82.67.190

[Mark Wilkinson]

Hmmmmm... and I thought that section of the API was unambiguous :-)  but
it appears that >66% of the services function the "right" way, so at
least some people are able to read my mind!!  ;-)  (or they copy/pasted
my service examples)

I seem to have not received some of the messages being quoted here...
but it sounds like there is general agreement that the behaviour (I
thought was) defined in the API, is a desirable one.  This behaviour is
also important for cases where, for example, the service HAS no input.
For example, consider a service that returns randomly chosen sequences
from a database.  The service takes no input, and returns FASTA as
output.  The only way to indicate to that service that you want it to
return 18 sequences would be to provide 18 mobyData blocks, each with
its own queryID, but otherwise empty.  An empty mobyData, in this case,
is not only expected but it would be hard to elicit this behaviour any
other way given the current API.

So, unless there is any objection, I or Eddie will clarify and tighten-
up the wording of this section of the API and send it out to everyone
for comment to make sure that it is clear enough, and that it accurately
represents the behaviour we need/expect.

v.v. the "isAlive" script that started this whole conversation:  AFAIK
the only client that reads the "isAlive" predicate in the LSID metadata
is the gbrowse_moby that is on MOBY Central.  I needed to "weed out"
dead services in order to re-submit the gbrowse_moby manuscript for
review.  (The last time I sent it to Bioinformatics the reviewers
rejected it because many services were dead... which is ridiculous, of
course... it's like rejecting Firefox as a browser because of404 errors!
Anyway... I wont be submitting it there again!)

thanks for all your input!  It was great to see a flurry of activity on
the list - it's reassuring that the project is still very much alive!

Cheers all!

Mark





On Tue, 2006-07-04 at 15:25 +0200, Björn Usadel wrote:
> Actually,
> 
> I interpreted it the same way, so I always send back a serviceNote 
> either 700_OK or whatever I consider the main error is at that moment.
> 
> However, I guess this should be ok, if only the mobyData block is 
> evaluated. Since exception and notes are decoupled from the data block. 
> A problem might rather be the statement that "the same" data block is 
> returned, since IMHO there would be different ways to write the same 
> message, but I guess this is covered by keepAlive.
> 
> I generally think it is a good idea, to test service availability and 
> would even support to go further as to supply input/output pairs. Since 
> I can figure out if a service is alive but not if I get back what I 
> expected (e.g. always an empty data block)
> 
> 
> The API description is here:
> "There must be as many mobyData response elements as there were mobyData 
> input elements (if a service can not respond to a specific query for 
> whatever reason, this element may be empty!)"
> 
> http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Docs/MOBY-S_API/OutputMessage.html
> 
> Cheers,
> Björn
> 
> Martin Senger wrote:
> >> It returns an empty mobyData block but because it fails the input 
> >> validation step - the service is not expecting an empty input mobyData 
> >> bloc,so it returns in the service note the exception code, 201 - 
> >> "INPUTS_INVALID"
> >>
> >    See, Mark? It seems that I am not the only one who did not know that
> > this is part of the API :-)
> > 
> >    Martin
> > 
> 
-- 

--
Mark Wilkinson
Asst. Professor, Dept. of Medical Genetics
University of British Columbia
PI in Bioinformatics, iCAPTURE Centre
St. Paul's Hospital, Rm. 166, 1081 Burrard St.
Vancouver, BC, V6Z 1Y6
tel: 604 682 2344 x62129
fax: 604 806 9274

"For most of this century we have viewed communications as a conduit, 
       a pipe between physical locations on the planet. 
What's happened now is that the conduit has become so big and interesting 
      that communication has become more than a conduit, 
       it has become a destination in its own right..."

                Paul Saffo - Director, Institute for the Future