Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

Hi,

At 09:20 28/09/2001 +0200, you wrote:
>Hi,
>
> > thats a lot of stuff and new thoughts which are mixed together.
> >
> >
> > - having static copy methods
> > - where the methods will reside
> > - putting complex code in base classes
> > - thinking about backend stuff
> > - putting a copy factory in topicmap
> >
> > Having static methods is sure a quite good deal. I don't really have
> >
> > a preference where they should live.
> > The static methods could reside in the object implementations while
> > they are object specific. On the other side every static methods
> > gets his working stuff as a parameter. This opens the options to
> > put them into an extra class.
> >
> > If I understand you right then the copyFactory has something to do
> > with the deep copy. In this situation we need a factory for creation
> > of subcomponents. If I assume the static methods we have
> >
> >       copy(Topic srcTopic, Topic destTopic, boolean deep)
> >
> > On the other site we have in TopicMap
> >
> >       setCopyFactory(TopicMapFactory copyFactory)
> >
> > I think it is dangerous to assume that the factory of destTopic and
> > copyFactory are always the same. In my opinion we should have an assurance
> > that the factory of e.g. a Topic and his components (BaseName, Occurrence)
> > is the same. If this isn't clear here a example:
> >
> >       Topic src;
> >       TopicMapFactory f1;
> >       TopicMapFactory f2;
> >       TopicMap tm;
> >
> >       tm.setCopyFactory(f1);
> >       Topic dest = f2.createTopic();
> >
> >       Topic.copy(src, dest, true);
> >
> > What will happen? A Topic src in a TopicMap from f1 and BaseNames
> > in TopicMap from f2 ??
> >
> > As long as I can see TopicMap is the only class which knows his factory.
> > That looks good. Is there any reason why a TopicMapObject shouldn't
> > know his Map? Every Object is only working in one TopicMap (through
> > references). If every TopicMapObjects knows his Map/Ownermap we could
> > check such things like illegal movement from one topicmap to another.
> > And we can always get the right factory through
> > this.getOwnerMap().getFactory();
> > This way we wouldn't need copyFactory, we could use loads of different
> > factories and the case of copying from a memory map to ozone is coped.
>
>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(...)

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

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.

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.

Thoughts ?

Cheers,

Kal