[ome-devel] Remote Framework: A review

[Zach Pincus]

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

On Mon, 16 Aug 2004 16:05:43 +0200, Joshua Moore
<j.moore at dkfz-heidelberg.de> wrote:
> Ok, one and all, I've reviewed our "C/C++ client ..." and "Existing
> client side..." threads which have been eating up bandwidth since
> mid-July. Where have we gotten?
> 
> The issues I picked up on are:
>     (1) Use what exists or make a change
>     (2) If there's a change, XML-RPC v. SOAP (or my last minute
> contender REST)
>     (3) High or low level API
>     (4) Heavy code on the client side versus server side
>     (5) Caching and miscellany.
> 
> In the end, our one requirement is usability. A high-level api would be
> gorgeous, but above all I want an api that I can give to non-web
> programmers (i.e. no experience with xml-rpc _OR_ soap) and they can
> start programming soon.
> 
> If this means, as Chris Allan pointed out early on, just documenting
> XML-RPC, sure, how do we go about it? Who, when?
> 
> I assume, though, in the process of defining that interface that's
> there's going to be a good deal we can build on. From that we can design
> a high level api. Or we can look into other technologies. Plus we can
> see where caching fits in. Etc.
> 
> I can decide none of this. My vote, however, is:
>     * Use xml-rpc for now (Doug can you generate the docs?)
>     * Use this as the basis for defining a low-level interface
>     * But, while defining the interface, re-evaluate xml-rpc before we
> put too much more effort into the current infrastrcture, then
>     * With whatever technology, put as much code on the server side
> within the restrictions placed by caching
>     * Develop ever higher level apis.
> 
> And above all, I need a timeline. I know it's summer and what the hell
> are we doing in the office anyway, right? But I have data that's waiting
> to jimmy it's way into OME (see the import thread), and developers who
> are trying to decide on data structures.
> 
> Let's come to consensus and get to work.
> Best wishes,
>   -Josh.
> 
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>