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

[Chris Allan]

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