[Tm4j-developers] Re: TopicMapSource implementation

[Kal A. <ka...@te...>]

On Mon, 2003-11-10 at 13:32, Harald Kuhn wrote:
> Hi Kal Ahmed,
> >
> > Hi Harald,
> > 
> > On Mon, 2003-11-10 at 12:58, Harald Kuhn wrote:
> > > Hi all, Hi Kal,
> > > 
> > > i have some problems with implementing the TopicMapSource. The ozone backend has its own XTMBuilder which does not implement the TopicMapBuilder interface. As i do not know Ozone well enough, i am not quite sure wether i can just use the XTMBuilder there ?!
> > > 
> > 
> > I don't think that you can just use the XTMBuilder directly in the Ozone
> > implementation as it currently is implemented. The Ozone implementation
> > passes chunks of XML data from the client to the Ozone server with the
> > actual parsing and object creation all happening on the server side.
> > This makes it a lot more efficient when in client/server mode. If you
> > like, I can take a look at that implementation.
> 
> Thats what i feared ...the question then is wether the TopicMapSource or the User should determine the Builder or wether we implement a OzoneTopicMapSource ... . On the other hand, if this is only an performance problem, then we should mybe just use the XTMBuilder and tell people to use the OzoneXTMBuilder if they want to implement something Ozone specific. We could also try to let OzoneXTMBuilder implement the TopicMapBuilder interface and just use it transparently ( e.g. SerializedTopicMapSource checks wether it gets an OzoneTM and then just uses the OzoneXTMBuilder if an XTM file was passed ) .
> 

I think that it is probably best to handle the Ozone backend as a
special case inside SerializedTopicMapSource. I wonder if the approach
of the OzoneXTMBuilder can be generalised. Currently chunking is
performed by a SAX parser on the client, but it might make more sense
for the client to simply send chunks of bytes to the parser and have all
parsing done on the server side. However, I think thats a bit more
hardcore Ozone programming than I really want to get into right now, so
its something to postpone for a post 0.9.0 alpha

> In the end it is definitly better, if you have a look at it, as it would probably take me far too long to figure this out (sorry i did not realise that the Ozone backend is so different there, when i made the proposal).
> 
No problem. I'll just implement the lazy solution for now :)

Cheers,

Kal
-- 
Kal Ahmed, Techquila
Standards-based Information Management
e: ka...@te...
w: www.techquila.com
p: +44 7968 529531