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

[Ilya Goldberg]

On Jul 19, 2004, at 1:12 PM, Chris Allan wrote:

> On Mon, Jul 19, 2004 at 12:21:59PM -0400, Harry Hochheiser wrote:
>>
>> Chris:
>>
>> yes, I know we're not currently using SOAP,  but the point is that we
>> could if we wanted to. In theory, we should just be able to swap 
>> around
>> a couple of libraries (some on the client and some on the server). If
>> there was enough value to be gained, this would be worth considering,
>> right? Or is there some inherent objection to even considering SOAP?
>
> We went down this road before with the first incarnation of the remote
> framework. It even worked simultaneously with SOAP and XML-RPC as a
> matter of fact. I fail to see what SOAP buys us other than service
> advertisment and automatic stub generation for our particular
> application. A migration to SOAP along the WSDL/UDDI lines would not
> just be a "swap around a couple of libraries" it would be a significant
> extension.

We're still using the same library as before (SOAP::Lite), which does 
SOAP and XMLRPC.  I think it would be trivial to make it serve 
everything over SOAP - especially if there was a WSDL.  Without a WSDL, 
SOAP is just completely useless.  Besides making SOAP useful, which 
admittedly is of dubious benefit, the WSDL serves the function of 
locking-down an API, which is a little too "casual" right now.  WSDL is 
an API language, right?  Sort of like a toy version of IDL for CORBA?  
If so, it would indeed be quite useful to think of the API in that way. 
  And if it lets all the .NET nutters in for free as well, so much the 
better.  And if its similar to IDL, then we can play CORBA too.  
Definitely more good than harm here.

As far as modifying and "extending" the back-end API, we have to keep 
in mind that the name of the game is "One API to Rule Them All".  So 
"extending" what we have in the back-end will have to necessarily 
propagate to the clients that we already have as well.  And in a way 
that would be as painless for the clients as possible.  Not saying this 
is impossible, but its not something we should approach casually at 
this point.

The best course it seems to me is to make a simple OME connector for C, 
which would essentially mean copying ome-java.
We could make this a little more complicated by defining the API in 
terms of how java agents use Shoola to make requests of the back end.  
This should definitely be split apart from the agent framework in 
Shoola anyway at some point.  Some (or all) of the calls defined this 
way could go directly to the back end.  Regardless, ome-java has to 
stick around because of its generality.  Anything we define as 
higher-level calls (in the Shoola style) would be additions.

I also think a C++ library will ultimately be less useful than C due to 
the inevitable portability problems.

-Ilya


>
>>
>> -harry
>>
>>
>> On Jul 19, 2004, at 10:32 AM, Chris Allan wrote:
>>> Yes, yes and yes. All fine and dandy if you're using SOAP. I'm fully
>>> aware of all of the above in terms of what most web services
>>> integrators
>>> like to call "fair play." However, as I said we are not using SOAP 
>>> and
>>> are not likely, unless you're volunteering and would think it of 
>>> great
>>> benefit, to migrate the entire remote framework and Java client 
>>> library
>>> to SOAP.
>>>
>>> The grid computing world, ah yes, with the largest project re-writing
>>> its entire implementation twice and planning to do it again, I don't
>>> think we're likely to jump on that boat. Not to mention they've got
>>> their own extensions to SOAP to make it "secure."
>>
>
> -Chris
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>