[ome-devel] Shoola-back-end consistency issues

[Ilya Goldberg]

On Jul 7, 2005, at 10:09 AM, Josh Moore wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Oh my goodness are there lots of ">" symbols in here...
>
> Ilya Goldberg wrote:
>
>>> We've got some csv things, and those are OK.  But there are still  
>>> holes
>>> left which require API-level access (like logging in, better queries,
>>> etc).  Csv is simple and good enough, and we have that:
>>> http://localhost/perl2/serve.pl?Page=OME::Web::
>>> DBObjTable&SessionKey=ce11152b03731da0832260ca336b53e8&Type=@Signal&@ 
>>> Sig
>>> nal.module_execution_id=187&Format=txt
>>> Having a good way to get the SessionKey and module_execution_id using
>>> our query tools via the API would be better though.
>
> This sounds interesting. Let's finally get around to some use cases.  
> For
>  _what_ do you want to get the SessionKey and mex_id? I was assuming
> something along the lines of:
>
>  getSpotsAsCSV(int imageId);

Well, this kind of call would need a VBA library if you want to issue  
it from Excel.  The URL above can be pasted into a Web Query and  
doesn't need VBA.  Excel doesn't implement cookies (at least not in my  
version), so some other way to exchange session tokens has to exist.   
You can do several queries to get a SessionKey (by doing a POST query  
with typed-in parameters for username/password), then get mex_id, etc.
Remember versioning?  What version of the image's spots are you after?   
That's why you need the mex_id.

>
> SessionKey is obviously sent in your request header. Give me an example
> of what you want in the API. (SVP)

I don't know what I want in the API.  I'm pretending to be Joe-user  
over here.  I know how to use Excel.  I probably don't know squat about  
VBA or APIs or anything of the sort.  I want my Find spots data in  
Excel, simple as that.  By any means necessary.

VBA would be fine to pretty this up a bit.  But then we need to provide  
example spreadsheets with all that stuff.  I couldn't even figure out  
how to do a URL request in VBA.  That's how dumb I am.

>>> Well, I don't know.  The idea is that everything you do is tied to a
>>> module - an action, whatever.  What do you suggest we call these  
>>> things
>>> that would encompass modules and actions?  They go through the same
>>> mechanism, so how would calling them different things help the user?
>
> I haven't done any polls or anything, but as I was getting into OME,
> there was a certain learning curve just to get the terminonology down.
> Perhaps this is the case no matter what we call things, but I have the
> feeling that our little language tends to alienate.

That's fine Josh.  Everyone's a critic.  How about some suggestions for  
what you think might work better?  I'm not saying what we have is  
perfect, its just better than anything else on the table.  Calling the  
same thing by different names seems like a bad idea unless you have  
some really good suggestion how to handle it.


>>> It does all sit in one place (more or less).  We don't have clients
>>> executing arbitrary modules yet, only specific tasks which are  
>>> handled
>>> by the API on the back-end.  We talked about a general AE-ish API in
>>> Baltimore that would let clients execute arbitrary modules, and I  
>>> think
>>> there was an actual plan.  Its not very complicated.
>
> This is less my concern than having clients make arbitrary API calls
> without being entangled with the AE.

Well, if they screw it up by making arbitrary API calls, the DB should  
return an error as a last resort.  Better if the error is caught both  
at the API level and the DB level.

As far as entanglement in the AE, this is an area of our API that can  
definitely stand some sprucing up.

-Ilya


>
> - -j.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFCzTeSIwpkR5bKmAsRAgI1AJ4/86TNFhtTSqh8CoQQaddPWnnOvACgiG4C
> frfKxzu9/PPvFMzoiPzrHy4=
> =aCtR
> -----END PGP SIGNATURE-----
>