[ome-devel] C/C++ client library for OME::Remote

[Chris Allan]

On Sun, Jul 18, 2004 at 04:35:16PM -0700, Zachary Pincus wrote:
> Hello,
> 
> From the feedback I've gotten, it looks like there are three options 
> for using OME XML-RPC outside of a Java environment:
> 
> (1) Put additional logic, similar to that of the Java client library, 
> into a C/C++ library that could be called from any language through 
> that language's C/C++ API. (This is how SWIG works, BTW -- it just 
> writes the biolerplate code needed to make a library available to a 
> given language through its C/C++ language bindings. Not sure how that 
> is any more of a hack than lex or yacc, or any code-generation tool.)

How you implement your particular scripting-language binding is quite
obviously up to you, and is really none of my business. I've personally
never been able to get SWIG to do what I want to do, but it has aways
been in the land of pain that is Perl XS so... guess I shouldn't
complain.

When in doubt blame the tool. :)

> 
> (2) Put this logic server-side, and then provide a higher-level XML-RPC 
> API than the current OME::Remote.
> 
> (3) Just use the current XML-RPC commands and build logic into the 
> client application as necessary.
> 
> Enough people have expressed interest in having a higher-level 
> interface that I think (3) is probably not the best way to go, though 
> I'm not sure. I'd love to hear what various people think about (1) 
> versus (2), possibly versus (3).

It seems to me that what we're weighing in terms of development is as
follows:

____________________
Extended XML-RPC API

* Provides more functionality but each client still has to implement the
  same client side logic
* We write lots of code and client developers still have to write a
  sizeable amount
* Client developers have to know XML-RPC as well as what to expect from
  the remote API

________________________________________
C/C++ library atop the XML-RPC framework

* Time consuming
* Provides significant client side functionality and specific services
  valid for client development
* Client developers have to learn our API and as such documentation has
  to be satisfactory

For obvious reasons, if I was a client developer I'd want to get the
most I could for free. Which makes developing a C/C++ library very
attractive. All of this said, it is hardly what one would call an easy
task.

> 
> The first has the advantage that one wouldn't have to know anything of 
> XML-RPC at all to use the code, thus lowering the bar. Also, some 
> things like caching (which the current Java code seems to spend a bit 
> of energy on) really have to be done client-side. It's also a more 
> constrained task, and there's already a Java implementation to follow.
> 
> The second has the advantage that the clients can be much 
> lighter-weight (and thus hewing to the web services "credo" better). 
> However, one could argue for various reasons that it's better for the 
> XML-RPC interface to stay pretty close to the Perl interface. Also the 
> task is a bit bigger and messier.
> 
> Before I invest time and effort into this, I'd like to make sure that 
> I'm going about it in a way that would provide the most benefit to 
> other users. So any final thoughts on this matter, before I dive in, 
> would be really appreciated.
> 
> Thanks,
> 
> Zach Pincus
> 
> Department of Biochemistry and Program in Biomedical Informatics
> Stanford University School of Medicine

Ciao.

-Chris