tm4j-developers

[Tm4j-developers] some thoughts of TopicMapCopier

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

Hi,

[kal]

I am very lucky to see that the copying stuff has just started.
It's one of those functionalities I need most these days.
I had a peak view at the TopicMapCopier class. And from there
some questions arose.

As long as I understand the copying problem it depends on
the origins (or factories/owners) of the objects and the type
of copying (shallow/deep).

involved objects/params are:

- sourceObject
- destObject (created from sourceObjects factory or a different one)
- shallow/deep copy switch

which in my thoughts would lead to a basic method

copy(srcObj, destObj, deep)

in case of class Topic:

copy(Topic srcTopic, Topic destTopic, boolean deep)

This method could be a static method of class topic.
Or like an example in Collections class collected
in a utility class (see Collections.copy(List,List)).

Having such static methods it is easy to create other
needed functionalities e.g. clone().

assuming factory is the factory of the topicmap containing
srcTopic a clone() method would be like that:

public Object clone()
{
    Topic dest = factory.createTopic();
    return copy(this, dest, false);
}

Additionally we don't need all time to create a util class
to duplicate an object.

If we have the copying functionality in the object itself
the utility class could cope with comfortability. In the
present TopicMapCopier the factory is always the same.
So we could store one specific factory in the TopicMapCopier
and create copies of Objects automagically.

This would lead from

    public Topic copy(Topic t)
    { ... }

    to

    public Topic copy(Topic t, boolean  deep)
    {
       Topic ret = m_dest.getFactory().createTopic....;
       return Topic.copy(t, ret, deep);
    }

or something similar.

I would also prefer not to use two different method names
like copy() and deepCopy(). If there are requirements to
have automated decision of shallow/deep this comes into place.
The kind of copy is done via a switch. A switch mostly forms
itself as an ifElse statements.
While the method names are chosen at compile time the programmer
using the API has to write an ifElse statement to decide which
copy should be made. With a switch in the method this functionality
moves into the API and appears more comfortable.
Additional there is the possibility to define a default behaviour
having a method without the switch parameter.

what do you think?

NoB

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

At 13:45 27/09/2001 +0200, Norbert Hartl wrote:
>Hi,
>
>[kal]
>
>I am very lucky to see that the copying stuff has just started.
>It's one of those functionalities I need most these days.
>I had a peak view at the TopicMapCopier class. And from there
>some questions arose.
>
>As long as I understand the copying problem it depends on
>the origins (or factories/owners) of the objects and the type
>of copying (shallow/deep).
>
>involved objects/params are:
>
>- sourceObject
>- destObject (created from sourceObjects factory or a different one)
>- shallow/deep copy switch
>
>which in my thoughts would lead to a basic method
>
>copy(srcObj, destObj, deep)
>
>in case of class Topic:
>
>copy(Topic srcTopic, Topic destTopic, boolean deep)
>
>This method could be a static method of class topic.
>Or like an example in Collections class collected
>in a utility class (see Collections.copy(List,List)).
>
>Having such static methods it is easy to create other
>needed functionalities e.g. clone().

Thats a good point.

>assuming factory is the factory of the topicmap containing
>srcTopic a clone() method would be like that:
>
>public Object clone()
>{
>    Topic dest = factory.createTopic();
>    return copy(this, dest, false);
>}

That could be done too.

>Additionally we don't need all time to create a util class
>to duplicate an object.

Definitely an advantage.

>If we have the copying functionality in the object itself
>the utility class could cope with comfortability. In the
>present TopicMapCopier the factory is always the same.
>So we could store one specific factory in the TopicMapCopier
>and create copies of Objects automagically.
>
>This would lead from
>
>    public Topic copy(Topic t)
>    { ... }
>
>    to
>
>    public Topic copy(Topic t, boolean  deep)
>    {
>       Topic ret = m_dest.getFactory().createTopic....;
>       return Topic.copy(t, ret, deep);
>    }
>
>or something similar.

Perhaps we could eliminate TopicMapCopier completely and make the factory 
to be used for creating copies into a p

>I would also prefer not to use two different method names
>like copy() and deepCopy(). If there are requirements to
>have automated decision of shallow/deep this comes into place.
>The kind of copy is done via a switch. A switch mostly forms
>itself as an ifElse statements.
>While the method names are chosen at compile time the programmer
>using the API has to write an ifElse statement to decide which
>copy should be made. With a switch in the method this functionality
>moves into the API and appears more comfortable.
>Additional there is the possibility to define a default behaviour
>having a method without the switch parameter.
>
>what do you think?
>
>NoB
>
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

OK, I'll try again without hitting Emacs control keys in a non-emacs 
environment ;-)

At 13:45 27/09/2001 +0200, Norbert Hartl wrote:
>Hi,
>
>[kal]
>
>I am very lucky to see that the copying stuff has just started.
>It's one of those functionalities I need most these days.
>I had a peak view at the TopicMapCopier class. And from there
>some questions arose.
>
>As long as I understand the copying problem it depends on
>the origins (or factories/owners) of the objects and the type
>of copying (shallow/deep).
>
>involved objects/params are:
>
>- sourceObject
>- destObject (created from sourceObjects factory or a different one)
>- shallow/deep copy switch
>
>which in my thoughts would lead to a basic method
>
>copy(srcObj, destObj, deep)
>
>in case of class Topic:
>
>copy(Topic srcTopic, Topic destTopic, boolean deep)
>
>This method could be a static method of class topic.
>Or like an example in Collections class collected
>in a utility class (see Collections.copy(List,List)).
>
>Having such static methods it is easy to create other
>needed functionalities e.g. clone().
>
>assuming factory is the factory of the topicmap containing
>srcTopic a clone() method would be like that:
>
>public Object clone()
>{
>    Topic dest = factory.createTopic();
>    return copy(this, dest, false);
>}
>
>Additionally we don't need all time to create a util class
>to duplicate an object.

These are all good points. I think you have convinced me that static copy 
methods would be a Good Thing. My reason for making the TopicMapCopier a 
separate object is that it uses only the standard interfaces and so is not 
implementation-specific. If we make static copy methods, then perhaps we 
should create abstract base classes in the org.tm4j.topicmap package which 
implement those methods.

As I typed that I began to think that there are some other pieces of pretty 
complex logic which might also be better off moved into an abstract base 
class to allow reuse in other backend implementations.


>If we have the copying functionality in the object itself
>the utility class could cope with comfortability. In the
>present TopicMapCopier the factory is always the same.
>So we could store one specific factory in the TopicMapCopier
>and create copies of Objects automagically.
>
>This would lead from
>
>    public Topic copy(Topic t)
>    { ... }
>
>    to
>
>    public Topic copy(Topic t, boolean  deep)
>    {
>       Topic ret = m_dest.getFactory().createTopic....;
>       return Topic.copy(t, ret, deep);
>    }
>
>or something similar.

Actually, perhaps it would be better to get rid of TopicMapCopier 
completely and to make the factory to be used for creating copied objects 
into a property of the TopicMap (or TopicMapUtils) interface, with a 
default value set to the factory used to create the topic map in the first 
place. That way, the static copy() functions can use a runtime-configured 
factory (enabling me to copy from an Ozone database into an in-memory 
implementation for local modification, for example).

>I would also prefer not to use two different method names
>like copy() and deepCopy(). If there are requirements to
>have automated decision of shallow/deep this comes into place.
>The kind of copy is done via a switch. A switch mostly forms
>itself as an ifElse statements.
>While the method names are chosen at compile time the programmer
>using the API has to write an ifElse statement to decide which
>copy should be made. With a switch in the method this functionality
>moves into the API and appears more comfortable.
>Additional there is the possibility to define a default behaviour
>having a method without the switch parameter.
>
>what do you think?

I was in two minds about that when I wrote the TopicMapCopier class...I'm 
not now sure why I chose to use two different names. I think it was because 
I felt that copy() and deepCopy() were getting overloaded enough...but if 
we have them in the interfaces, then that problem goes away and a boolean 
flag is appropriate.

So in summary:

1) implement copy() in each object interface - note, this includes 
interfaces such as TopicMapObject
2) Put the implementations in abstract base classes and change the memory 
and ozone implementations to extend the base classes.
2) Add a getCopyFactory() method to TopicMap which defaults to the factory 
used for the TopicMap
3) Add a setCopyFactory() method to TopicMap which enables the user to 
provide a new Factory to use for copying
4) copy() supports deep and shallow copies according to the value of a 
boolean flag passed in to the copy() method.


>NoB
>
>
>_______________________________________________
>Tm4j-developers mailing list
>Tm4...@li...
>https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

Oops,

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.


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?

If this sounds reasonable kals proposal of base classes would
lead to the only implementation of logic/administrative topicmap
specific code. The other part will then be a plugable backend
provider which provides any i/o operation on the backend.


just a few words to confuse the world around me :)


sincerely,

NoB

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

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

Hi,

At 11:18 28/09/2001 +0200, Norbert Hartl wrote:
>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? :))

Thats Gerd Mueller, developer of the Ozone back-end


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

OK. This is where I think we are. There are thre approaches to copying 
currenlty on the table

1) The back-end independent copier object method - as represented by 
TopicMapCopier
2) Norbert's suggestion that copy() functions be implemented as part of the 
interfaces of TopicMapObject and derived classes
3) Gerd's suggestion that copy() functions be implemented as part of the 
interface of TopicMapFactory

Then there are extra ideas flying round related to each of (2) and (3). As 
far as I can tell, (2) and (3) are equivalent in terms of functionality. 
(3) has the advantage that the factory being used for making the copy is clear.

Lets try and resolve the issue of which approach to take first and then 
analyze that approach in more detail. If we find problems, we can always 
return to the "choosing an approach" step again!

Lets move discussion of changes to the back-end into a separate thread.

Cheers,

Kal

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

Kal Ahmed wrote:

> Hi,
> 
> At 11:18 28/09/2001 +0200, Norbert Hartl wrote:
> 
>> 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? :))
> 
> 
> Thats Gerd Mueller, developer of the Ozone back-end
> 
> 

Yes I know :) I just got your reply to Gerds mail earlier
than Gerds mail itself.


>>
>> - which interfaces would be changed?
>> - where is the copy implementation?
> 
> 
> OK. This is where I think we are. There are thre approaches to copying 
> currenlty on the table
> 
> 1) The back-end independent copier object method - as represented by 
> TopicMapCopier
> 2) Norbert's suggestion that copy() functions be implemented as part of 
> the interfaces of TopicMapObject and derived classes
> 3) Gerd's suggestion that copy() functions be implemented as part of the 
> interface of TopicMapFactory
> 

Just to stress this point enough. Every solution has to be 
backend-independent.
It is (without any doubt) a good idea to prefer (3). I like the idea because
inside a copy method the create..() methods are needed. And the Factory 
is the
place where they reside.
Should we put the copy implementation in the TopicMapFactory. This will 
change
TopicMapFactory to an abstract class. If we don't like this idea we should
have a further look at (1).


NoB

Re: [Tm4j-developers] some thoughts of TopicMapCopier

[Gerd M. <ge...@sm...>]

> >> - which interfaces would be changed?
> >> - where is the copy implementation?
> > 
> > 
> > OK. This is where I think we are. There are thre approaches to copying 
> > currenlty on the table
> > 
> > 1) The back-end independent copier object method - as represented by 
> > TopicMapCopier
> > 2) Norbert's suggestion that copy() functions be implemented as part of 
> > the interfaces of TopicMapObject and derived classes
> > 3) Gerd's suggestion that copy() functions be implemented as part of the 
> > interface of TopicMapFactory
> > 
> 
> Just to stress this point enough. Every solution has to be 
> backend-independent.
> It is (without any doubt) a good idea to prefer (3). I like the idea because
> inside a copy method the create..() methods are needed. And the Factory 
> is the
> place where they reside.

Thats the reason why I prefer (3). copy() is also some kind of creation method 
and should be a method of the factory. Also if we use approach (2) we would need
to pass a factory to the copy() method of the TopicMapObject. This looks somehow
odd to me.

> Should we put the copy implementation in the TopicMapFactory. This will 
> change
> TopicMapFactory to an abstract class. If we don't like this idea we should
> have a further look at (1).

bye,
gerd

--
________________________________________________________________
Gerd Mueller                                    ge...@sm...     
SMB GmbH                                  http://www.smb-tec.com

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

At 17:32 28/09/2001 +0200, Gerd Mueller wrote:

> > >> - which interfaces would be changed?
> > >> - where is the copy implementation?
> > >
> > >
> > > OK. This is where I think we are. There are thre approaches to copying
> > > currenlty on the table
> > >
> > > 1) The back-end independent copier object method - as represented by
> > > TopicMapCopier
> > > 2) Norbert's suggestion that copy() functions be implemented as part of
> > > the interfaces of TopicMapObject and derived classes
> > > 3) Gerd's suggestion that copy() functions be implemented as part of the
> > > interface of TopicMapFactory
> > >
> >
> > Just to stress this point enough. Every solution has to be
> > backend-independent.
> > It is (without any doubt) a good idea to prefer (3). I like the idea 
> because
> > inside a copy method the create..() methods are needed. And the Factory
> > is the
> > place where they reside.
>
>Thats the reason why I prefer (3). copy() is also some kind of creation 
>method
>and should be a method of the factory. Also if we use approach (2) we 
>would need
>to pass a factory to the copy() method of the TopicMapObject. This looks 
>somehow
>odd to me.

Well I prefer (3) as well. So it looks like we are agreed to try this way 
unless Florian has any objections.

I have a little free time now so I might try and look at this today. 
However, I'll move the existing source code over to org.tm4j before 
starting work on this.

Cheers,

Kal

Re: [Tm4j-developers] some thoughts of TopicMapCopier

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

tmHi,


> 
> Thats the reason why I prefer (3). copy() is also some kind of creation method 
> and should be a method of the factory. Also if we use approach (2) we would need
> to pass a factory to the copy() method of the TopicMapObject. This looks somehow
> odd to me.
> 
No, this is a misunderstanding. My idea proposal started from a ownerMap reference

in TopicMapObject. Via this one you can get the according factory from any
TopicMapObject via this.getOwnerMap().getFactory(). So, there is no need 
to have
factory as parameter at all. So it's very easy to have a static method 
while every
objects carries his factory with it. I mentioned that with this approach
the location of the implementation of such a copy method is arbitrary.
The factory is hidden inside the objects.
Our both approaches aren't that different. Its just a matter what object 
references
to carry to methods of other objects.

Example GUI:

In this situation we have a component which is able to modify e.g. an 
topic object.
In order to be able to cancel any modification the component should work 
on a copy
object instead of the original topic.
With your approach code will look like this:

	Topic src, tmpTopic;
	Component topicComp;
	TopicMapFactory copyFactory;

	tmpTopic = copyFactory.copy(src);
	topicComp.setFactory(copyFactory); // you'll need this because comp may 
create new
	topicComp.setTopic(tmpCopy);

Mine would like this:

	Topic src, tmpTopic;
	Component topicComp;
	TopicMapFactory copyFactory;

	tmpTopic = copyFactory.createTopic();
	tmpTopic.copy(src);
	topicComp.setTopic(tmpCopy);

The main difference of those both is that in your approach we don't need a reference

inside TopicMapObject but we have to carry the Factory ourselfs around.


I wrote this only to make clear my intentions. This doesn't cancel my 
agreement to your
solution.

have a nice day,

NoB

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

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