[ome-devel] Remote Framework: A review

[Ilya Goldberg]

Hey guys
One of the reasons we went with XMLRPC in the first place is that its  
imminently hackable.  You want a call to do something specific from a  
remote C client?  No problemo.  Hack it up in perl on the back-end,  
publish the method, and off you go.  You can dress up the XMLRPC-C  
library to shield the poor innocents from having to de-marshall the  
generic XMLRPC call on the client.  Its really easy, probably less than  
an afternoon's work.
Make a new Facade, say "perl2/OME/Remote/Facades/HackFacade.pm", and  
put your method in there.  Add "OME::Remote::Facades::HackFacade" to  
the list in perl2/OME/Remote/Facade.pm", and you're good to go.
Of course, its a hack.  The point is that if you need it yesterday, you  
can do it.

About the only thing that would be helpful in this case is to have a  
helper method on the client to log in and get a SessionKey.  A  
bare-bones skeleton library on the client would use XMLRPC-C to do the  
heavy lifting, and a thin shell around it to pretty it up.  I would  
recommend doing something like this anyway with some of your specific  
use cases before committing to doing a lot of design for a client-side  
library.  Its good to get a feel for things before going off on a big  
design project.  Measure once, cut twice I say.

Sorry there's no FM to read.  The Remote framework has gone through  
some changes and has really only stabilized with the current release.   
But ask, and yee shall be guided.

With regards to the "API", I do think that this is something that needs  
to be specified in some sort of API specification language just so that  
it is very specific, all its rules are enforceable, and there would be  
some chance to achieve consistency in the API across all languages (DOM  
is a good example of this - we're really trying to achieve the same  
thing as was done with DOM).  I don't know a great deal about this, but  
it seems like either CORBA IDL or WSDL would be appropriate.  Ideally,  
the Java and C client-side interfaces should be similar if not  
identical, but I'm not even sure if this is possible.  My bias is to do  
the least amount of work possible.  If we specify the ome-java  
interface in IDL or WSDL, can't we just have an appropriate compiler  
spit out our C bindings and not have to do anything else?

If that's asking for a little too much, then at least having the API  
specification will be something to hang your hat on and will keep  
everyone from wandering off into their own little corners.  Since  
ome-java is the most generic and low-level API we have, its the right  
place to start.  Even if we eventually do something more high-level, we  
will still need this low-level API for its generality.  If its too  
complicated to do what you want immediately, then hack away.  Once  
ome-C is in existence, you can arrange things so that the end-point  
client uses ome-C in an identical way to what you hacked up for the  
short term (i.e. using its own little wrapper around ome-C instead of  
around XMLRPC-C).

-Ilya



On Aug 17, 2004, at 8:42 AM, Joshua Moore wrote:

> Zach et al.
>
> I think the Java API is useable, but nevertheless a bit complex for my  
> most urgent needs[1]. I'll give you a use case:
>
>    A biologist-turned-C-programmer has time-series images. He came to  
> me looking for a sensible data structure for his routine. I pointed  
> him to Tikal's data structures, but told him, if you can hang on just  
> a bit, we'll pull it directly out of OME and you'll be ready for the  
> next wave of Cool.
>    His code needs to: pull the stack out of OMEIS and the time-stamps  
> that belong to them, i.e. just one ST from OMEDS. Nothing else. And  
> until I can get that running, he's twiddling his thumbs.
>
> As far as waiting on a lone grad student, heaven forbid. If we've come  
> (or can come) to consensus, I've got at least one full-timer that I  
> can put on this. (He's twiddling his thumbs, too.)
>
> Josh.
>
> [1] I think this complexity is a sign that code can be shifted to the  
> server, because otherwise the exact same functionality would have to  
> be duplicated in C.
>
> Zach Pincus wrote:
>
>> Hello all,
>>
>> Sorry to have been out of the loop on this, but I've been on the road
>> the last couple of days (and for the next week or so).
>>
>> Anyhow, Josh, how does the Java API look in terms of usability? (see
>> http://cvs.openmicroscopy.org.uk/horde/chora/cvs.php/OME-JAVA/src/ 
>> org/openmicroscopy/ds?login=2
>> , and in particular, the Factory and Manager classes). If an API is
>> provided that looks like that, is that usable enough to point coders
>> at? Because, if the wrapper API is sound and usable, the transport
>> layer's usability is basically unimportant, right? I think that the
>> Java API Doug has made is pretty usable and clear (and
>> well-documented).
>>
>> I ask about the Java API because I'm trying to provide basically the
>> same functionality in the mythical C library. Which brings me to part
>> two: because I'm away, I'm not sure what an ETA for the C client will
>> be. Under a month?
>>
>> Anyhow, I've got it prototyped out, and I'll make the API public as I
>> finish each layer so people could code against a thin wrapper around
>> the XML-RPC before I get any of the DTO things totally debugged... But
>> if waiting on me (a lone grad student currently on vacation) isn't
>> your cup of tea, perhaps you/we'll need to look at something else.
>>
>> Zach
>>
>
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>