[ome-devel] Existing client side code in C

[Harry Hochheiser]

Zach:

You raise some good points - let me respond to some in particular....:

> 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?
>

This question has come up with the current Java lib, which does not put 
any effort into maintaining a single DTO for any given DB Object.  The 
client code in OME-Java is essentially stateless, in the sense that 
each request is independent of any other and there is no attempt made 
to cache data, reconcile objects, etc.  In addition to creating some 
potentially nasty situations  for the code, it creates potential 
network costs: if an object X is requested n times, n trips will be 
made across the network to get it.

Thus, what we'd really like to have is some sort of caching layer that 
would enforce some sort of object uniqueness. However, as you point 
out, it's potentially troublesome. If  anyone has ideas about how to 
work around these details, I'd love to hear them.

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

Right. I don't have any particular ideas off-hand here, but I have to 
agree -maybe it would help to take a step back and think about what 
would make sense without following the Java implementation..In any 
case, I think you might have to live with the possibility of multiple 
DTOs/ DB object..

harry