[ome-devel] Remote Framework: A review

[Joshua Moore]

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.