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

[Josh Moore]

-----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);

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


>> OMG.  Why two MEXes?  Can two modules issue the very same output?  Its 
>> a logical fallacy.

Don't know why two MEXes. Just checking the boundary conditions.


>> 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.


>> 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.

- -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-----