[MOBY-l] locateServiceByInput - what does "@IN" mean?

[David Block]

> -----Original Message-----
> From: Matt Links [mailto:mlinks at gene.pbi.nrc.ca]
> Sent: Thursday, May 16, 2002 9:21 AM
> To: David Block
> Cc: moby-l at biomoby.org
> Subject: re: [MOBY-l] locateServiceByInput - what does "@IN" mean?
> 
> 
> > > The MOBY-Central call "locateServiceByInput" takes a list 
> > > (should be a list
> > > reference, actually - I'll fix that) of input Objects as 
> one of its
> > > parameters.  Should MOBY-Central return only the services 
> > > which take as input
> > > *all* Objects in that list, or should it return the services 
> > > which take one or
> > > more of the objects in that list?
> 
> Why wouldn't there be both calls (or one more flexible call) present 
> in the api?  If this is implemented like a standard search 
> engine then the 
> client can put the constraints on the inputs as the client sees fit.
> 

This makes sense - although the query (in the ISYS model) will be generated by something as simple as a right-mouse click (how am I going to do that on my Mac? :) (please don't respond to that)
So ideally the client should not have to do much to generate the query, and there should be only one network transaction to get the possible results back.  

<rabbit-trail>These should be cached by clients, btw, so that the second time you offer these three types of objects you can check to see the age of your cached reply and just serve that.  This will allow real right-click access to Moby services (which will change slowly).  There should always be an option to delete the cache.</rabbit-trail>

There is little difference between getting the one service back that you want and eleven possible services that you want in terms of latency, since it should be one request/one SQL call/one response.  Then the client can choose from the provided options.  If you want to do the 'only provide matches for all types' option, that can be set in a prefs facility somewhere so that it isn't a concern at the moment of querying.

This moby thing will definitely be fun when it's up.  I can see coding a Java client in my future.  I'll just need to prove the business case first.

> > "Always be liberal in what you accept, strict in what you emit."
> 
> If you are completely liberal in what you accept isn't the 
> extension to 
> allow anything as input.
> 
> "Give me anything and I'll give you something"
> 
> ;-)

Not a bad idea - over the internet with multiple clients, you'll likely get lots of versions of the spec co-habiting.  It makes sense to do the server in Perl to allow lots of Do What I Mean.
> 
> 
> Matt
> 

-Dave
Java: making easy things possible.