Re: Re: [Tm4j-tmnav-dev] StoreManager Implementation

[Christoph F. <cf...@fo...>]

Hi Martin,


Am Mon, 2003-09-01 um 00.01 schrieb Martin Stockhammer:
> Yes that's true. I saw this. I would like to put all the tm4j-dependencies into the
> panckouckeStore and make the StoreManagerImpl only dependent on the panckoucke
> api.
Fine. I skimed over StoreManagerImpl and I agree with you that this can
be done without causing much pain. 
 
> I think the store implementation are very dependent on the backend that is used. 
> So I thought to create a store implementation for each individual backend and let
> the StoreManager choose the right store-Implementation for it's task, dependent
> on the current context.
> For example it might be possible, that a client has its local store for some topic
> maps and wants to use the webservice for other topicmaps.
> 
I begin to see what you are planning. This sounds indeed very attractive
to me. 
> But on the first view I see some problems if we uses store implementations parallel.
> The Locator-Adresses must be unique for each store implementation. Merging of
> topicmaps over different stores is very likely not possible (any ideas?).
> 
I don't see a problem with the Locators. The StoreManager could decide
on a protocol/part-of-uri base which Store it should use. This should
rule out that a Topicmap at a given URI can be loaded by two different
Stores (assuming all loading is done via the StoreManager). Orrrr do I
miss something here?

About merging. Most likely the StoreManager must be responsible to
ensure that both TopicMaps are hold by the same store. In the worst case
it have to import one Map into another store temporarily. I don't know
if this is practicable, maybe it works for small maps and maybe this is
all what we want (thinking of editing).


> So I think a easy implementation would be to switch between different 
> store implementations, that means to use one or the other but not both parallel.
> 
> The only thing to do would be to define a common interface for all store implementations,
> and put a new method to the StoreManager to choose a implementation.
Defining a new Interface should be pretty straightforward. This is at
least my impression after scanning through the StoreManagerImpl-code.

> 
> That are my ideas. If you say it's complete bullshit it's ok, but tell me why.  I don't know
> if it makes really sense. So please tell me your opinons about this subject.
> 

I like the idea. Maybe it would open us some doors and allows us doing
things we are currently no thinking of. I'm not sure. On the other hand,
I think it eats some time.

If you want to go for it, I will be glad to give you all support I am
able too (which wouldn't be too much).

Maybe a more efficient approach would be to write a new
StoreManagerImpl, along with a new Store and keep your ideas in mind.
Which would essentially mean to use the same methodnames as
PanckouckeStore does.
  
That way we could start working with kamal and collect some experience.
If we come to the point, that it is desirable to access Topicmaps from
different oeh.. streams, backends, protocol ? how would you name it?..
we can more or less easily adopt the existing work and unifies it.

What do you think?
Bye
c

 
> About the jars: Yes I think it would be a good thing to put the api on one jar,
> and the implemenations in another jar.
> 
> 
> Bye 
> 
> Martin
> 
> 
> 
> Christoph Froehlich <cf...@fo...> schrieb am 30.08.03 12:11:03:
> > 
> > Hi Martin
> > 
> > The panckoucke StoreManagerImpl class depends partly on
> > org.tm4j.topicmap.*-classes. 
> > If you use the StoreManagerImpl class on the client side of the
> > webservice, you are introducing tm4j-dependencies at the client. Since
> > avoiding this was one of the design goals of the panckoucke api,  I
> > wonder if kamal clients shouldn't use an all new implementation  of the
> > StoreManager-Interface.
> > 
> > Maybe it would be helpful to split the panckoucke-distribution into two
> > jars? One containing the api and one containing the default
> > implementation?
> > 
> > 
> > Bye
> > c
> > 
> > 
> > 
> > 
> > 
> > Am Fre, 2003-08-29 um 11.42 schrieb Martin Stockhammer: 
> > > Hi,
> > > 
> > > I looked at the current StoreManagerImpl and saw that it uses the
> > > PanckouckeStore class
> > > for managing the TopicMap-Providers.
> > > 
> > > For the webservice-Panckoucke-Client I'm thinking about to create an
> > > enhanced StoreManagerImpl-Class
> > > that can use multiple stores (e.g. PanckouckeStore, WebserviceStore).
> > > The StoreManager chooses
> > > the backend store depending on the ProviderFactory-Class given by
> > > createProvider(...).
> > > I'm wondering if this enhanced StoreManagerImpl would be convenient
> > > for Panckoucke too and if there
> > > are objectons and suggestions of you about it.
> > > 
> > > 
> > > Bye
> > > 
> > > Martin
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > --
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Tm4j-tmnav-dev mailing list
> > > Tm4...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tm4j-tmnav-dev
> > 
> > -- 
> > 
> > Christoph Froehlich <cf...@fo...>
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Tm4j-tmnav-dev mailing list
> > Tm4...@li...
> > https://lists.sourceforge.net/lists/listinfo/tm4j-tmnav-dev
> 
> 
> __________________________________________________________________________
> Die sicherste Form der Kommunikation: E-Mails verschluesseln, Spam-Filter,
> Adressverifizierung, digitale Unterschrift: http://freemail.web.de
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Tm4j-tmnav-dev mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-tmnav-dev
-- 
Christoph Froehlich <cf...@fo...>