Re: [Tm4j-developers] some thoughts of TopicMapCopier

[Norbert H. <rue...@se...>]

Hi,


this is a strange email. From whom are those interim quotes?
I can only recognize quotes to my mail and then on top
there are kals quotes. Who is this in between? :))

 >>
 >> Maybe I missed some point in this discussion, but why not having
 >> a copy() method at the factory interface ? Then I would write:
 >>
 >>   Topic t = factory.copy( topic, true );
 >>
 >> Then it would be clear in which topicmap the copy resists and it
 >> doesn't matter where the source comes from.
 >
 >
 > That's another good idea - after all, it may be possible for different
 > implementations to optimize the copy operation if they are all held in a
 > single base class. Of course, that makes a clone() operation more
 > difficult to implement, but only slightly so. If we implemented the
 > TopicMap back-pointer in TopicMapObject, then an object could do clone
 > by calling getTopicMap().getFactory().copy(...)
 >


Ok, now I'm just not sure if everybody talks about the same issue.
Let's fix this:

- which interfaces would be changed?
- where is the copy implementation?


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


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


NoB