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

[Zachary Pincus]

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

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

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


On Jul 18, 2004, at 4:52 AM, Chris Allan wrote:

> On Tue, Jul 13, 2004 at 02:29:09PM -0700, Zachary Pincus wrote:
>> Hmm, I seem to have touched on something here. Seems such a library
>> could be useful.
>>
>> As one grad student, I can't do a whole lot big-picture-wise, but I am
>> still interested in working on a C/C++ XML-RPC client implementation.
>>
>> If I could solicit some advice to get started:
>> (1) Should I start out by simply aping the Java client library, or
>> would there be a better approach? (Start by producing a WSDL and
>> implement a client compliant with that?) Realistically, the only thing
>> I can do alone is to replicate what the Java can do. If others want to
>> help, the scope could be expanded...
>
> I'm not sure exactly why people are talking about WSDL. WSDL is 
> designed
> for SOAP, not XML-RPC. We have an XML-RPC web services implementation,
> not SOAP. Why you'd need automatic stub generation and service
> advertisment for such a simple RPC protocol I have no idea. Document
> the exposed XML-RPC procedure calls and forget about a layer of complex
> and overly verbose XML descriptors on top.
>
>> (2) How much of a moving target are these APIs, etc? Should I hold off
>> for a while before trying to write a portable client library?
>> (3a) How do people feel about JNI? Sure, writing a C interface that
>> calls the Java on the back-end, and is called by Perl/Python/&c. on 
>> the
>> front end is a huge and ridiculous hack, but it might be quicker and 
>> at
>> least the client codebase is unified...
>> (3b) Would C be substantially better than C++, language-binding-wise?
>> (SWIG does fine with clean C++, but I'm not sure about bindings to C#,
>> or anything else not covered by SWIG. Plus it's hard to call C++ from
>> C, but that's probably not a huge problem, is it?)
>
> This is not what I mean when I say "language binding." I would never 
> use
> Swig for taking an existing C or C++ library and calling it from Perl,
> Python or other scripting language of your choice. There are scripting
> language native tools for doing this already. Perl's XS and Python's C
> API as examples. The whole point behind a C or C++ library with 
> language
> bindings in mind is to avoid (IMHO of course) cross-language hacks like
> Swig.
>
> If you're going to go through all the effort of building a library in C
> or C++, tying it to the JNI on one side seems a bit silly. The amount 
> of
> development and user overhead to get something like this working cross
> platform strikes me as huge.
>
>>
>> Any thoughts, advice, et al. would be appreciated,
>
> Your best bet seems to be extending the existing XML-RPC server side
> framework. Right now it is extremely low level and requires existing
> knowledge of the Perl server side API. The "ome-java" library
> encapsulates much of this logic into a client usable API. Obviously,
> this is far from what web services were initially designed to
> accomplish.
>
> Extending this existing implementation also gives you the freedom to
> develop in any scripting language's XML-RPC client framework without
> also also developing the scripting language's binding to a C or C++
> library.
>
>>
>> Zach
>
> Hope this helps.
>
> Ciao.
>
> -Chris
>