[ome-devel] Existing client side code in C

[Zachary Pincus]

Hello all,

I'm happy to participate in another round of brainstorming about what 
needs to be implemented, and more than happy to work with some others 
on getting a DS and IS client together.

I don't have anything prototyped except in my head, but I've been 
spending some quality time thinking through what needs to be done for a 
DS client in C or C++. Thus far, most people have voted for C, which 
although a bit nastier (see my previous email in this thread) will do 
fine, especially in a libwww/libcurl world.

There are certainly some hairy issues about such a client that I would 
like to consult with some people on. For one, dealing with the DTOs -- 
reconstituted gobs of serialized OME data -- is likely to get a bit 
troublesome. For example, how best to deal with "instantiating" these 
DTO objects as they come over the wire. At run-time, the client will 
need to set up proper objects in memory for an incoming DTO, and will 
only know the name of the object type as a string. C and C++ clearly 
don't have a good "Class.ForName" mechanism to do run-time-typed 
object/struct creation, so the client will need to provide a similar 
facility (e.g. a big nasty hashtable mapping strings to "constructor" 
function pointers). Also, if done in C, the best this facility can do 
is pump out void *'s which need to be cast to whatever type they ought 
to be. Perhaps there then needs to be a type-safe down-casting 
mechanism?

Another question: should there be an effort to maintain only a single 
DTO in memory for any given DB object? If not, clients can get into 
nasty situations if they aren't careful. If so, then there needs to be 
active memory management to deal with the fact that several DTO objects 
can point at a different DTO object. Unfortunately, reference counting 
fails because it is all too easy to set up a circular reference. Is 
there then a need to have a mark-and-sweep "garbage collector" (though 
not necessarily a traditional GC running in a different thread)? Or do 
you just insist that the DTO objects form proper trees in memory and 
ignore the fact that there might/will be multiple client-side objects 
for a single remote DB object?

But at this point, it sounds like instead of implementing a C client 
for OME, I'm trying to implement Java (garbage collection, 
run-time-typed objects, dynamic casting). It is quite possible that 
this is the wrong approach. Part of the problem is that I've been 
trying to think of ways to stay close to the OME-Java interface and 
implementation, which may not be particularly right for a C-style 
client library. Maybe there's a better and more natural way to do this 
all in C. So yeah, I'd love to brainstorm.

Zach Pincus

Department of Biochemistry and Program in Biomedical Informatics
Stanford University School of Medicine



On Aug 10, 2004, at 6:09 AM, Joshua Moore wrote:

> Ok. After a discussion among several of our developers, we'd like to 
> make something of a proposal.
>
> We have a standalone C++ GUI which does various image processing 
> tasks. It's called Tikal, and the folks in Dundee have seen an albeit 
> less-than-perfect demonstration. It is used by our department, several 
> other departments of the DKFZ, and by the folks at EMBL. Perhaps 
> others, but it's certainly our main imaging platform.
>
> We are in the process of getting our users onto OME, this of course 
> dependent on import and export. (Hence this and my previous thread.)  
> Leaving imports aside for a moment, the most critical step for us now 
> is to allow Tikal to access the OME servers, both DS and IS. (DS is 
> important for getting the time stamp info, Ilya, which we need for 
> simulations.) With such a comunication library, Tikal quickly becomes 
> YAOC (Yet another OME client).
>
> What we'd suggest is that we combine our efforts. We can start working 
> together with Zachary on a libcurl/libwww solution ( though I think we 
> need to return to the XML-RPC/SOAP discussion ). Chris, it might be 
> helpful if you posted/submitted to CVS your code. Also, Zach, do you 
> have anything prototyped? Perhaps another round of brainstorming is in 
> order to work out some implementation details. Then we'll get started.
>
> That's the first part of the discussion. The second deals with Tikal 
> itself. Tikal was (thankfully) designed to operate mostly as a 
> library. There's a thin layer of OpenGL that does 3D visualization, 
> etc. ...Perhaps I'll just open this up for debate: does it make sense, 
> once we have the C bindings, to provide Tikal as a library and rewrite 
> the 3D code in JOGL for Shoola, or do you see a benefit in having a C 
> client?
>
> Ok. Enough for today. I'm going to the lake.
> -Josh.