Next Generation Back-ends (was Re: [Tm4j-developers] some thoughts of TopicMapCopier)

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

Hi

I've taken the liberty of separating the copier discussion from the 
back-end discussion:

At 11:18 28/09/2001 +0200, Norbert Hartl wrote:
> >> >
> >> > backend ideas:
> >> >
> >> > Today I asked about the interface and implementation stuff of the
> >> > backends. My thoughts were the same as kals that there should
> >> > be the possibility to have a single implementation of topicmap
> >> > administrative code.
> >> > At the moment there is an API which copes with TopicMaps and not
> >> > with backends. Through the lack of a definition of a backend the
> >> > TM API itself is made backend specific. For me thats the point
> >> > of doubling implementation in the memory and ozone code.
> >> > I think the backend has total different requirements than the
> >> > TopicMap. If we could define the requirements for a backend
> >> > and turn them into atomic backend operations and then into interfaces
> >> > we could easily build a pluggable backend. I don't know if there
> >> > are reasons while this would be a too heavy task. Gerd?
> >>
> >> That'S a nice idea. It would make it easier to develop other
> >> backends. But I'm not sure if it is really that easy to define
> >> such atomic operations. Do you've got any ideas on that ?
> >
>
>We have already something similar. A lot of Collection classes are
>used. In a simple understanding the interface of the Collections
>are one part of i/o operation (set,get,add,...). additionally there
>are implemented enhancements coping with the needs of a backend.
>This should be a good starting point to define such operations.
>
>
> >
> > I can think of two possible approaches:
> >
> > 1) A lot of the complexity is due to maintenance of various indices. All
> > the indexes are currently held as Hashtables or the like. Perhaps it
> > would be better to make these indices into first-class objects with
> > defined interfaces. Then a back-end would be responsible for
> > implementing persistent storage of the objects and the indices, and we
> > could slice off the index maintenance logic and make it back-end
> > independent. Essentially, we would implement the existing API in two
> > layers, an API layer providing the logic on top of an SPI layer
> > providing persistent storage and indexing services.
> >
>
>I'm off on this issue. I'm lacking detailled knowledge on the inner
>side of the API. Could you explain in a few words how the present
>structure acts?

The present structure really has both SPI and logic combined in a single 
layer. Basically, to implement the com.techquila.topicmap.* interfaces, you 
need to provide both the persistent storage and the logic for handling 
indexes, updates, deletions and so on. This makes development of a back-end 
a long and difficult process (sorry Florian! ;-). I am suggesting that we 
separate the logic that handles object updates, additions and deletions 
from the object and index persistence layer so that a backend needs only to 
implement the storage part.


> > 2) Implement a back-end service provider interface that requires the
> > implementation of a simpler data model such as PMTM4's node and arc
> > model, plus its supporting indexes then implement topic map specific
> > logic on top of that. If we are careful with such an implementation, it
> > might be possible to develop a single SPI which could support XTM and
> > ISO 13250 based APIs and could even support other node/arc based
> > technologies such as RDF.
> >
>
>That sounds intriguing. I don't know anything about PMTM4. Do you have
>links about this stuff?

Sorry, I meant to include one before I sent it. See 
http://www.topicmaps.net/pmtm4.htm

Cheers,

Kal