Menu
▾
▴
tm4j-tmnav-dev — Discussions relating to the development of the tmnav sub-project.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(8) |
Mar
(12) |
Apr
(11) |
May
(12) |
Jun
(6) |
Jul
(6) |
Aug
(6) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(17) |
Nov
(2) |
Dec
|
| 2005 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Harald K. <har...@we...> - 2003-10-09 19:21:54
|
Hi all, some of the interfaces i added to panckoucke and its web implementation have a beginning I to indicate this. I discussed this with Niko and Christoph and we decided to rename these interfaces to make the project more homogeneous. I will start with it this weekend if nobody objects. Cheers, Harald ______________________________________________________________________________ Horoskop, Comics, VIPs, Wetter, Sport und Lotto im WEB.DE Screensaver1.2 Kostenlos downloaden: http://screensaver.web.de/?mc=021110 |
|
From: Christoph F. <cf...@fo...> - 2003-09-18 16:10:48
|
Hi panckoucke now contains a tolog-abstractor which returns you an AbstractModel for a given tolog-query. To learn more about the shape of the model, please see the diagramm located in doc/html/images tmnav now contains a tolog-window (under the edit-menu) which allows you to enter a query and see the result in a tree view. All is still very rough and incomplete. Especially it is not possible to add inference rules to the tolog engine. I hope to fix this soon. bye c -- Christoph Froehlich <cf...@fo...> |
|
From: Christoph F. <cf...@fo...> - 2003-09-09 08:00:41
|
hi all I just stumbled over the panckoucke-convenience methods AbstractionNodeUtil.addNode(AMModel, Topic [, AMGestalt]) These methods encapsulate the creation of an AMNode for a given Topic. They are using the dataLocator-Property of the Node to hold a reference to the *subject* of the represented Topic. To me, it seems more intuitive, that the dataLocator of that node holds a reference to the *resourceLocator* of the represented Topic. I would like change the code, but since theese methods are central regarding the creation of AbstractModels, I would like to hear, if anyone uses this "feature" (Feature: the dataLocator of an AMNode, which represents a Topic, points to the subject of this Topic). I know that TMNav does not use it, but maybe some other clients of panckoucke does? Or am I on the wrong track? Is it preferable to reference the subject than to reference the resourceLocator of the represented Topic?? Regards c -- Christoph Froehlich <cf...@fo...> |
|
From: Kal A. <ka...@te...> - 2003-09-07 12:48:33
|
On Sat, 2003-09-06 at 11:26, Harald Kuhn wrote: > Hi Kal, > > I did some work on the jndi sharing and now have a first running version (for tomcat only, at the moment). I will check it in soon, however i am not completely shure where and inside which package. At the moment the package is org.tm4j.jndi and subpackages. As it only depends on tm4j and this feature maybe interesting for other subprojects ass well, it mybe a good idea to add it there. > Cool! I think it would be best to check it in to the tm4j project - org.tm4j.jndi seems like a good package location to me. > I also started working on the SVGRenderer and the appearance of the svg is now (at least in parts) configurable via a properties file (i will check that in with the initial version of the jndi sharing). > > I also had a look at them tmbrowse webapp but could not deploy it using ant because of a . bug in the ant file: > > BUILD FAILED: Target `jar' does not exist in this project. It is used from target `tmbrowse-deploy'. > DOH! I've checked in the fix for that now. Once you have the JNDI code checked in, I'll look at modifying tmbrowse to use that. Cheers, Kal -- Kal Ahmed, Techquila Standards-based Information Management e: ka...@te... w: www.techquila.com p: +44 7968 529531 |
|
From: Harald K. <har...@we...> - 2003-09-06 10:26:53
|
Hi Kal, I did some work on the jndi sharing and now have a first running version (for tomcat only, at the moment). I will check it in soon, however i am not completely shure where and inside which package. At the moment the package is org.tm4j.jndi and subpackages. As it only depends on tm4j and this feature maybe interesting for other subprojects ass well, it mybe a good idea to add it there. I also started working on the SVGRenderer and the appearance of the svg is now (at least in parts) configurable via a properties file (i will check that in with the initial version of the jndi sharing). I also had a look at them tmbrowse webapp but could not deploy it using ant because of a . bug in the ant file: BUILD FAILED: Target `jar' does not exist in this project. It is used from target `tmbrowse-deploy'. > Hi Harald, > > On Wed, 2003-08-13 at 15:42, Harald Kuhn wrote: > > Hi Kal, > > > > it took me some time to make some basic code cleanup (there is still a > > lot of work to do ) and to find some bugs. > > One is escpecially confusing and I am starting to think that it is maybe > > not a problem of the webapp code. When loading a TM with the panckoucke > > context, > > it sometimes because of a duplicate object id and sometimes not. I will > > make an officiall posting after i can descripe the problem in more > > detail (exceptions, tm etc.). > > That would be really helpful, thanks. Sorry still did not find the time to look into that in detail. > > However I checked in the code some minute ago and I also updated the war > > file which i added some days ago. > > I think the two next major steps would be to work on the svg renderer > > (e.g. make it more configurable, mybe finish the one i started that uses > > javascript to show occurrences resource data as a tooltip) and to > > implement the jndi sharing. > > I had a short look at foafnaut and it really looks nice. Did you see > > lmtm (www.tmtm.de)? It is a site hosted by a teacher for usage in > > school. It is in German but that should not be that much of a problem. > > > > It looks good - I guess it is using the same SVG rendering code ? Actually not, it was kind of a parallel development. lmtm uses cocoon and xslt to transform a static topicmap into these pages. I stumbeld over it while i tried to create SVG using the ontopia navigator tag libraries but realised, that these approache was to restricted. > (BTW the URL is www.lmtm.de :) Sorry for that! > I think that TM4Web should be aiming to make > this kind of application really easy to construct. Cool stuff! That is exactly what I had in mind, too :). Cheers Harald ______________________________________________________________________________ 38xTestsieger - WEB.DE FreeMail - Deutschlands beste E-Mail zum Patent angemeldetem 3-Wege-Spam-Schutz- http://f.web.de/?mc=021130 |
|
From: Christoph F. <cf...@fo...> - 2003-09-04 11:55:08
|
Hi Martin PanckouckeStore is the one and only central repository where panckoucke holds topicmaps. It is a singleton and designed for concurrent requests. Different StoreManager may access this single instance of the store and benefit from already loaded maps. For example there could be a StoreManager-Implementaton which controls access to topicmaps and considers privileges. For every User such a StoreManager could be instantiated but panckoucke doesn't have to load every topicmap for every user. When planing SessionManagement for Kamal, you may consider to instantiate a StoreManager for every session. Or make your SessionObject an implementation of StoreManager... Just some thoughts. Bye c Am Die, 2003-09-02 um 23.08 schrieb Martin Stockhammer: > Yes, you are right. And after looking more closely on the PanckouckeStore-Class, > I found it's interface is almost the same as the StoreManager-Interface. > Defining a interface for the PanckouckeStore would lead to the StoreManager-Interface. > So, there is no really benefit with an extra interface. > I'm wondering why the PanckouckeStore is apart from the StoreManagerImpl? > > But we should keep the idea in mind, I think. I will implement my own StoreManager-Class. > And in the future we could think about a general StoreManager-Implementation that > uses different StoreManager-Implementations in the background (and maybe a communication > protocol between the stores for exchanging maps). > > > Bye > > Martin > > > > > Christoph Froehlich wrote: > > 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...> |
|
From: Kal A. <ka...@te...> - 2003-09-02 21:11:24
|
On Sun, 2003-08-31 at 23:01, Martin Stockhammer wrote: > 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. > 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. > > 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?). > Take a look at the org.tm4j.topicmap.unified package. Its a kind of read-only, dynamic merging of topic maps which should work across different stores. It doesn't do name-based merging, but it does do subject indicator and subject address merging. It would probably be quite bandwidth-intensive across multiple web services unless you were able to do some local caching (this is what my P2P application does - the Unified backend is actually a unified view of the cached data and the working data and the cache is added to as the user browses around this unified view). Cheers, Kal -- Kal Ahmed, Techquila Standards-based Information Management e: ka...@te... w: www.techquila.com p: +44 7968 529531 |
|
From: Christoph F. <cf...@fo...> - 2003-09-02 07:32:20
|
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...> |
|
From: Martin S. <hu...@we...> - 2003-08-31 23:03:58
|
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. 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. 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?). 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. 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. 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 |
|
From: Christoph F. <cf...@fo...> - 2003-08-30 10:09:59
|
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...> |
|
From: Martin S. <hu...@we...> - 2003-08-29 09:43:25
|
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 |
|
From: Martin S. <hu...@we...> - 2003-08-25 16:07:10
|
Hi, there is now some documentation for Kamal in the CVS (doc/html). It's just a start, so tell me if some parts need more explanation. I hope I can provide a sample Java client implementation soon, that allows to use the Panckoucke API transparently over the webservice (I think if it works it would be a good reason for a first release number). After that I will finish the Session Management. Bye Martin |
|
From: Kal A. <ka...@te...> - 2003-08-13 21:19:07
|
Hi Harald, On Wed, 2003-08-13 at 15:42, Harald Kuhn wrote: > Hi Kal, > > it took me some time to make some basic code cleanup (there is still a > lot of work to do ) and to find some bugs. > One is escpecially confusing and I am starting to think that it is maybe > not a problem of the webapp code. When loading a TM with the panckoucke > context, > it sometimes because of a duplicate object id and sometimes not. I will > make an officiall posting after i can descripe the problem in more > detail (exceptions, tm etc.). That would be really helpful, thanks. > However I checked in the code some minute ago and I also updated the war > file which i added some days ago. > I think the two next major steps would be to work on the svg renderer > (e.g. make it more configurable, mybe finish the one i started that uses > javascript to show occurrences resource data as a tooltip) and to > implement the jndi sharing. > I had a short look at foafnaut and it really looks nice. Did you see > lmtm (www.tmtm.de)? It is a site hosted by a teacher for usage in > school. It is in German but that should not be that much of a problem. > It looks good - I guess it is using the same SVG rendering code ? (BTW the URL is www.lmtm.de :) I think that TM4Web should be aiming to make this kind of application really easy to construct. Cool stuff! Cheers, Kal -- Kal Ahmed, Techquila Standards-based Information Management e: ka...@te... w: www.techquila.com p: +44 7968 529531 |
|
From: Harald K. <har...@we...> - 2003-08-13 15:04:37
|
Hi Kal, it took me some time to make some basic code cleanup (there is still a lot of work to do ) and to find some bugs. One is escpecially confusing and I am starting to think that it is maybe not a problem of the webapp code. When loading a TM with the panckoucke context, it sometimes because of a duplicate object id and sometimes not. I will make an officiall posting after i can descripe the problem in more detail (exceptions, tm etc.). However I checked in the code some minute ago and I also updated the war file which i added some days ago. I think the two next major steps would be to work on the svg renderer (e.g. make it more configurable, mybe finish the one i started that uses javascript to show occurrences resource data as a tooltip) and to implement the jndi sharing. I had a short look at foafnaut and it really looks nice. Did you see lmtm (www.tmtm.de)? It is a site hosted by a teacher for usage in school. It is in German but that should not be that much of a problem. Cheers, Harald Kal Ahmed wrote: >Hi Harald, > >I think that the best thing to do is to check in the code in the folders >that you suggest and then see where we go from there. > >My guess is that the best thing to do would be to work on the >TopicMapViewer application and use our experience on that to drive the >development of the tm4web.panckoucke and vtl-panckoucke packages. Have >you seen foafnaut (http://foafnaut.org) that browses FOAF files in SVG ? >Thats a really nice (SVG) ui perhaps something like that could be the >eventual target. I think that the code for foafnaut is open source so it >should be possible to gain some implementation ideas from it as well as >inspiration ! > >I like the idea of being able to use JNDI to share topic map providers >between applications - it would be a big saving with the in-memory topic >map provider and with the unified topic map backend too. > >Cheers, > >Kal > __________________________________________________________________________ Die sicherste Form der Kommunikation: E-Mails verschluesseln, Spam-Filter, Adressverifizierung, digitale Unterschrift: http://freemail.web.de |
|
From: Christoph F. <cf...@fo...> - 2003-07-27 18:15:46
|
Hi Harald Am Son, 2003-07-27 um 18.16 schrieb Harald Kuhn: > Hi Christoph, > > thank you for your suggestion. However i think that as long as we can > get around changeing the API, we schould do without. By adding a > method like: > > ProviderReference addProvider(TopicMapProvider tmp) > > we would loose part of the decoupeling from the tm4j api which was one > of the design issues of your api Good point. I did forget this (shame about me) and you are absolutely right. We should not change the api! But I'm curious how you plan to interact with panckoucke. Since you have no TopicMapProviderReference for you TopicMapProvider. Are you planning to bypass the api? > which i liked best (because one does not need to look into three > different api documentations to use the panckocuke lib). > So i would like to first try the JNDI sharing and choose the API > change as the second way. > Go ahead with JNDI. To me, this is always interesting technology. And if you run into some problems we are always free to write a Util-Method that is capable to add an existing instance of TopicMapProvider to the Store. Bye c > Thanks again & cheers > > Harald > > > > > > > Hi Harald, > > > > glad to hear that you found some spare time... > > I'm really looking forward to see your results. > > > > About the Provider: > > It would be little effort adding a method to the > > StoreManager-Interface, which allows you to add a already > initialized > > Provider. > > > > like this: > > ProviderReference addProvider(TopicMapProvider tmp) > > > > I'm not sure if this is exactly what you are looking for, but if > this > > would help you I could easily implement it. > > > > bye > > c > > > > > > Am Die, 2003-07-22 um 12.06 schrieb Harald Kuhn: > > > Hi Kal, > > > > > > thanks, the exams were ok! Eclipse seems to be the tool of coice > for the whole tm4j team :). > > > > > > The prototype works with struts / jsp so there is no velocity > support at the moment. > > > This is no problem however, because most of the work is anyway > done in the actions etc. The SVG (for example) is generated inside the > renderer, so the only place some presentation logic is needed there is > to take the result of the rendering (a String containing the SVG) and > show it somewhere with the ending .svg (for Adobe SVG Plugins sake). > As the parts for configuration and direct selection of the Topic > etc.(my navigation) is not needed if combined with the "text" > > > presentation. We just need to write some little code that takes > the SVG String and writes it out. > > > > > > In my opinion the main problem with integrating it is, that > panckoucke works with an abstraction layer and wraps the TopicMaps etc > with its own classes (e.g. TopicMapReference etc.). Moreover the api > is designed in a way, that there is no approved way to add a provider > to the StoreManager (the management component for TopicMaps and > Providers). Because > > > of this, we cant just use an abstractor with the TopicMap held > inside the TM4Web classes. We could A) change the API or B) find a way > around it. I am for B at the moment (but thats maybe because I already > have a soultion in mind [see later]:). > > > Panckoucke has the context for the general configuration. My app > works with the panckoucke context and retrieves a specified TopicMap, > Abstractor and Renderer from the context (this is done by ids and the > baseLocatorAdress). So the only thing we have to do in terms of > configuration is to specify ids for Renderer and Abstractor and the > baseLocatorAdress > > > for the TopicMap (the actions expect ServletContext attributes > with the names TOPICMAP, RENDERER and ABSTRACTOR). I think in doing it > this way, everything is decoupled enough so that both parts can still > be used seperately. > > > > > > For sharing the providers, I experimented with a JNDI Wrapper. The > idea was to export a Provider though JNDI. The wrapper looks up the > shared provider and calls its appropriate methods. I did this for > beeing able to share the same TopicMaps between two different webapps. > But I think we could also use it here ?! > > > > > > I am eager to learn what kind of ideas you have about this > problems! > > > > > > > > > For the checkin, i suggest the following: > > > > > > - a folder TopicMapViewer for my demo app > > > (i would like to keep it out of two reasons, it can be used to > play with the panckoucke code and > > > it is an example of using tm4web with jsp) > > > - a folder panckoucke with the packages org.tm4j.tm4web.panckoucke > [and subpackages] for the > > > panckoucke related implementations (e.g. the SVG Renderer - this > would give use more > > > seperation, the panckoucke stuff will only be used as a jar file > in the struts / velocity app) > > > - the package org.tm4j.vtl-panckoucke and > org.tm4j.vtl-panckoucke.struts for the actions etc. > > > > > > > > > So if you have no major objections, I think the best way to do > this is for me to check in everything so that everybody interested can > have a look at it. Afterwards we can start implementing the combined > app (or whats missing for it). > > > > > > Cheers, > > > Harald > > > > > > > Hi Harald, > > > > > > > > On Fri, 2003-07-18 at 08:15, Harald Kuhn wrote: > > > > > Hi Kal, > > > > > as i finished my this years exams earlier this week, I do now > have a bit of spare time to work on the integration of the > TopicMapViewer into the TM4Web Project. > > > > > > > > > Cool! Glad to have you back...I hope the exams went well. > > > > > > > > I'm really happy that you are wiling to contribute to this > project > > > > because there are a lot of cool things to do! > > > > > > > > > What are your plans for the TM4Web Project at the moment ? Do > you have any wishes, ideas etc, for the integration ? I would like to > suggest mergeing the struts / velocity based tm4web module with the > now struts and panckoucke based code in order to get graphical and > textual navigation and presentation for TopicMaps. > > > > > > > > > > > > > My plans are really just to get it documented and released as > soon as > > > > possible. However I think your proposal of merging the > panckoucke > > > > framework with the is a good idea but I would like to be sure > that the > > > > "vanilla" TM4J velocity integration also remains. I think that > it should > > > > be possible to do this by extending the configuration file > syntax a > > > > little. Currently the configuration file specifies a template to > use to > > > > render a topic or all topics of a specific type. We could extend > it to > > > > specify a panckoucke abstractor to be used as well... would that > fit > > > > with the design of your package ? > > > > > > > > > I followed your suggestion and started porting the prototypes > "buisness logic" to struts. It already works relatively well (if one > ignores the fact that in order to change the renderer, one sometimes > has to restart the application :) ). > > > > > I created a Servlet which uses the new PanckouckeContext to > create and hold the panckoucke related configuration (TopicMaps, > Abstractors, Renderers) as well as a couple of struts actions. > > > > > > > > > > > > > Cool - do you think it would be easy to integrate this directly > into the > > > > existing Velocity servlet in TM4Web ? > > > > > > > > > > > > > What do you think would be the best place for the code and the > demo application inside the TM4Web directory ? > > > > > I would like to suggest using the java package > org.tm4j.tm4web.graphical for the java code and maybe a new directory > for the TopicMapViewer. I think the TopicMapViewer is interesting > enough (in terms of technologie demo and experimental development > platform) to keep it. > > > > > > > > That sounds good to me. Perhaps the Velocity code can go into > the > > > > velocity subdirectory...there is a package org.tm4j.vtl for the > Velocity > > > > stuff (which is where the current Velocity servlet is) and > > > > org.tm4j.vtl.struts for the Struts forms and actions. If we are > going to > > > > integrate the code you have then I think it makes sense to match > that > > > > layout. Perhaps org.tm4j.vtl-panckoucke and > > > > org.tm4j.vtl-panckoucke.struts ? > > > > > > > > Well, whatever you decide is fine - moving classes around is > quite easy > > > > with Eclipse :) > > > > > > > > Cheers, > > > > > > > > Kal > > > > > > > > > > > > > > > > > > ______________________________________________________________________________ > > > Wo gibt es den besten Spam-Schutz? Computerbild 15-03 sagt bei > > > WEB.DE FreeMail - Deutschlands beste E-Mail - > http://s.web.de/?mc=021123 > > -- > > Christoph Froehlich <cf...@fo...> > > > > > ______________________________________________________________________________ > ComputerBild (15-03) empfiehlt: Der beste Spam-Schutz ist bei > WEB.DE FreeMail - Deutschlands beste E-Mail - > http://s.web.de/?mc=021124 -- Christoph Froehlich <cf...@fo...> |
|
From: Harald K. <har...@we...> - 2003-07-27 16:16:58
|
Hi Christoph, thank you for your suggestion. However i think that as long as we can get around changeing the API, we schould do without. By adding a method like: ProviderReference addProvider(TopicMapProvider tmp) we would loose part of the decoupeling from the tm4j api which was one of the design issues of your api which i liked best (because one does not need to look into three different api documentations to use the panckocuke lib). So i would like to first try the JNDI sharing and choose the API change as the second way. Thanks again & cheers Harald > > Hi Harald, > > glad to hear that you found some spare time... > I'm really looking forward to see your results. > > About the Provider: > It would be little effort adding a method to the > StoreManager-Interface, which allows you to add a already initialized > Provider. > > like this: > ProviderReference addProvider(TopicMapProvider tmp) > > I'm not sure if this is exactly what you are looking for, but if this > would help you I could easily implement it. > > bye > c > > > Am Die, 2003-07-22 um 12.06 schrieb Harald Kuhn: > > Hi Kal, > > > > thanks, the exams were ok! Eclipse seems to be the tool of coice for the whole tm4j team :). > > > > The prototype works with struts / jsp so there is no velocity support at the moment. > > This is no problem however, because most of the work is anyway done in the actions etc. The SVG (for example) is generated inside the renderer, so the only place some presentation logic is needed there is to take the result of the rendering (a String containing the SVG) and show it somewhere with the ending .svg (for Adobe SVG Plugins sake). As the parts for configuration and direct selection of the Topic etc.(my navigation) is not needed if combined with the "text" > > presentation. We just need to write some little code that takes the SVG String and writes it out. > > > > In my opinion the main problem with integrating it is, that panckoucke works with an abstraction layer and wraps the TopicMaps etc with its own classes (e.g. TopicMapReference etc.). Moreover the api is designed in a way, that there is no approved way to add a provider to the StoreManager (the management component for TopicMaps and Providers). Because > > of this, we cant just use an abstractor with the TopicMap held inside the TM4Web classes. We could A) change the API or B) find a way around it. I am for B at the moment (but thats maybe because I already have a soultion in mind [see later]:). > > Panckoucke has the context for the general configuration. My app works with the panckoucke context and retrieves a specified TopicMap, Abstractor and Renderer from the context (this is done by ids and the baseLocatorAdress). So the only thing we have to do in terms of configuration is to specify ids for Renderer and Abstractor and the baseLocatorAdress > > for the TopicMap (the actions expect ServletContext attributes with the names TOPICMAP, RENDERER and ABSTRACTOR). I think in doing it this way, everything is decoupled enough so that both parts can still be used seperately. > > > > For sharing the providers, I experimented with a JNDI Wrapper. The idea was to export a Provider though JNDI. The wrapper looks up the shared provider and calls its appropriate methods. I did this for beeing able to share the same TopicMaps between two different webapps. But I think we could also use it here ?! > > > > I am eager to learn what kind of ideas you have about this problems! > > > > > > For the checkin, i suggest the following: > > > > - a folder TopicMapViewer for my demo app > > (i would like to keep it out of two reasons, it can be used to play with the panckoucke code and > > it is an example of using tm4web with jsp) > > - a folder panckoucke with the packages org.tm4j.tm4web.panckoucke [and subpackages] for the > > panckoucke related implementations (e.g. the SVG Renderer - this would give use more > > seperation, the panckoucke stuff will only be used as a jar file in the struts / velocity app) > > - the package org.tm4j.vtl-panckoucke and org.tm4j.vtl-panckoucke.struts for the actions etc. > > > > > > So if you have no major objections, I think the best way to do this is for me to check in everything so that everybody interested can have a look at it. Afterwards we can start implementing the combined app (or whats missing for it). > > > > Cheers, > > Harald > > > > > Hi Harald, > > > > > > On Fri, 2003-07-18 at 08:15, Harald Kuhn wrote: > > > > Hi Kal, > > > > as i finished my this years exams earlier this week, I do now have a bit of spare time to work on the integration of the TopicMapViewer into the TM4Web Project. > > > > > > > Cool! Glad to have you back...I hope the exams went well. > > > > > > I'm really happy that you are wiling to contribute to this project > > > because there are a lot of cool things to do! > > > > > > > What are your plans for the TM4Web Project at the moment ? Do you have any wishes, ideas etc, for the integration ? I would like to suggest mergeing the struts / velocity based tm4web module with the now struts and panckoucke based code in order to get graphical and textual navigation and presentation for TopicMaps. > > > > > > > > > > My plans are really just to get it documented and released as soon as > > > possible. However I think your proposal of merging the panckoucke > > > framework with the is a good idea but I would like to be sure that the > > > "vanilla" TM4J velocity integration also remains. I think that it should > > > be possible to do this by extending the configuration file syntax a > > > little. Currently the configuration file specifies a template to use to > > > render a topic or all topics of a specific type. We could extend it to > > > specify a panckoucke abstractor to be used as well... would that fit > > > with the design of your package ? > > > > > > > I followed your suggestion and started porting the prototypes "buisness logic" to struts. It already works relatively well (if one ignores the fact that in order to change the renderer, one sometimes has to restart the application :) ). > > > > I created a Servlet which uses the new PanckouckeContext to create and hold the panckoucke related configuration (TopicMaps, Abstractors, Renderers) as well as a couple of struts actions. > > > > > > > > > > Cool - do you think it would be easy to integrate this directly into the > > > existing Velocity servlet in TM4Web ? > > > > > > > > > > What do you think would be the best place for the code and the demo application inside the TM4Web directory ? > > > > I would like to suggest using the java package org.tm4j.tm4web.graphical for the java code and maybe a new directory for the TopicMapViewer. I think the TopicMapViewer is interesting enough (in terms of technologie demo and experimental development platform) to keep it. > > > > > > That sounds good to me. Perhaps the Velocity code can go into the > > > velocity subdirectory...there is a package org.tm4j.vtl for the Velocity > > > stuff (which is where the current Velocity servlet is) and > > > org.tm4j.vtl.struts for the Struts forms and actions. If we are going to > > > integrate the code you have then I think it makes sense to match that > > > layout. Perhaps org.tm4j.vtl-panckoucke and > > > org.tm4j.vtl-panckoucke.struts ? > > > > > > Well, whatever you decide is fine - moving classes around is quite easy > > > with Eclipse :) > > > > > > Cheers, > > > > > > Kal > > > > > > > > > > > > ______________________________________________________________________________ > > Wo gibt es den besten Spam-Schutz? Computerbild 15-03 sagt bei > > WEB.DE FreeMail - Deutschlands beste E-Mail - http://s.web.de/?mc=021123 > -- > Christoph Froehlich <cf...@fo...> > ______________________________________________________________________________ ComputerBild (15-03) empfiehlt: Der beste Spam-Schutz ist bei WEB.DE FreeMail - Deutschlands beste E-Mail - http://s.web.de/?mc=021124 |
|
From: Kal A. <ka...@te...> - 2003-07-23 18:52:38
|
Hi Harald, I think that the best thing to do is to check in the code in the folders that you suggest and then see where we go from there. My guess is that the best thing to do would be to work on the TopicMapViewer application and use our experience on that to drive the development of the tm4web.panckoucke and vtl-panckoucke packages. Have you seen foafnaut (http://foafnaut.org) that browses FOAF files in SVG ? Thats a really nice (SVG) ui perhaps something like that could be the eventual target. I think that the code for foafnaut is open source so it should be possible to gain some implementation ideas from it as well as inspiration ! I like the idea of being able to use JNDI to share topic map providers between applications - it would be a big saving with the in-memory topic map provider and with the unified topic map backend too. Cheers, Kal On Tue, 2003-07-22 at 11:06, Harald Kuhn wrote: > Hi Kal, > > thanks, the exams were ok! Eclipse seems to be the tool of coice for the whole tm4j team :). > > The prototype works with struts / jsp so there is no velocity support at the moment. > This is no problem however, because most of the work is anyway done in the actions etc. The SVG (for example) is generated inside the renderer, so the only place some presentation logic is needed there is to take the result of the rendering (a String containing the SVG) and show it somewhere with the ending .svg (for Adobe SVG Plugins sake). As the parts for configuration and direct selection of the Topic etc.(my navigation) is not needed if combined with the "text" > presentation. We just need to write some little code that takes the SVG String and writes it out. > > In my opinion the main problem with integrating it is, that panckoucke works with an abstraction layer and wraps the TopicMaps etc with its own classes (e.g. TopicMapReference etc.). Moreover the api is designed in a way, that there is no approved way to add a provider to the StoreManager (the management component for TopicMaps and Providers). Because > of this, we cant just use an abstractor with the TopicMap held inside the TM4Web classes. We could A) change the API or B) find a way around it. I am for B at the moment (but thats maybe because I already have a soultion in mind [see later]:). > Panckoucke has the context for the general configuration. My app works with the panckoucke context and retrieves a specified TopicMap, Abstractor and Renderer from the context (this is done by ids and the baseLocatorAdress). So the only thing we have to do in terms of configuration is to specify ids for Renderer and Abstractor and the baseLocatorAdress > for the TopicMap (the actions expect ServletContext attributes with the names TOPICMAP, RENDERER and ABSTRACTOR). I think in doing it this way, everything is decoupled enough so that both parts can still be used seperately. > > For sharing the providers, I experimented with a JNDI Wrapper. The idea was to export a Provider though JNDI. The wrapper looks up the shared provider and calls its appropriate methods. I did this for beeing able to share the same TopicMaps between two different webapps. But I think we could also use it here ?! > > I am eager to learn what kind of ideas you have about this problems! > > > For the checkin, i suggest the following: > > - a folder TopicMapViewer for my demo app > (i would like to keep it out of two reasons, it can be used to play with the panckoucke code and > it is an example of using tm4web with jsp) > - a folder panckoucke with the packages org.tm4j.tm4web.panckoucke [and subpackages] for the > panckoucke related implementations (e.g. the SVG Renderer - this would give use more > seperation, the panckoucke stuff will only be used as a jar file in the struts / velocity app) > - the package org.tm4j.vtl-panckoucke and org.tm4j.vtl-panckoucke.struts for the actions etc. > > > So if you have no major objections, I think the best way to do this is for me to check in everything so that everybody interested can have a look at it. Afterwards we can start implementing the combined app (or whats missing for it). > > Cheers, > Harald > > > Hi Harald, > > > > On Fri, 2003-07-18 at 08:15, Harald Kuhn wrote: > > > Hi Kal, > > > as i finished my this years exams earlier this week, I do now have a bit of spare time to work on the integration of the TopicMapViewer into the TM4Web Project. > > > > > Cool! Glad to have you back...I hope the exams went well. > > > > I'm really happy that you are wiling to contribute to this project > > because there are a lot of cool things to do! > > > > > What are your plans for the TM4Web Project at the moment ? Do you have any wishes, ideas etc, for the integration ? I would like to suggest mergeing the struts / velocity based tm4web module with the now struts and panckoucke based code in order to get graphical and textual navigation and presentation for TopicMaps. > > > > > > > My plans are really just to get it documented and released as soon as > > possible. However I think your proposal of merging the panckoucke > > framework with the is a good idea but I would like to be sure that the > > "vanilla" TM4J velocity integration also remains. I think that it should > > be possible to do this by extending the configuration file syntax a > > little. Currently the configuration file specifies a template to use to > > render a topic or all topics of a specific type. We could extend it to > > specify a panckoucke abstractor to be used as well... would that fit > > with the design of your package ? > > > > > I followed your suggestion and started porting the prototypes "buisness logic" to struts. It already works relatively well (if one ignores the fact that in order to change the renderer, one sometimes has to restart the application :) ). > > > I created a Servlet which uses the new PanckouckeContext to create and hold the panckoucke related configuration (TopicMaps, Abstractors, Renderers) as well as a couple of struts actions. > > > > > > > Cool - do you think it would be easy to integrate this directly into the > > existing Velocity servlet in TM4Web ? > > > > > > > What do you think would be the best place for the code and the demo application inside the TM4Web directory ? > > > I would like to suggest using the java package org.tm4j.tm4web.graphical for the java code and maybe a new directory for the TopicMapViewer. I think the TopicMapViewer is interesting enough (in terms of technologie demo and experimental development platform) to keep it. > > > > That sounds good to me. Perhaps the Velocity code can go into the > > velocity subdirectory...there is a package org.tm4j.vtl for the Velocity > > stuff (which is where the current Velocity servlet is) and > > org.tm4j.vtl.struts for the Struts forms and actions. If we are going to > > integrate the code you have then I think it makes sense to match that > > layout. Perhaps org.tm4j.vtl-panckoucke and > > org.tm4j.vtl-panckoucke.struts ? > > > > Well, whatever you decide is fine - moving classes around is quite easy > > with Eclipse :) > > > > Cheers, > > > > Kal > > > > > > > ______________________________________________________________________________ > Wo gibt es den besten Spam-Schutz? Computerbild 15-03 sagt bei > WEB.DE FreeMail - Deutschlands beste E-Mail - http://s.web.de/?mc=021123 -- Kal Ahmed <ka...@te...> techquila |
|
From: Christoph F. <cf...@fo...> - 2003-07-22 10:37:59
|
Hi Harald, glad to hear that you found some spare time... I'm really looking forward to see your results. About the Provider: It would be little effort adding a method to the StoreManager-Interface, which allows you to add a already initialized Provider. like this: ProviderReference addProvider(TopicMapProvider tmp) I'm not sure if this is exactly what you are looking for, but if this would help you I could easily implement it. bye c Am Die, 2003-07-22 um 12.06 schrieb Harald Kuhn: > Hi Kal, > > thanks, the exams were ok! Eclipse seems to be the tool of coice for the whole tm4j team :). > > The prototype works with struts / jsp so there is no velocity support at the moment. > This is no problem however, because most of the work is anyway done in the actions etc. The SVG (for example) is generated inside the renderer, so the only place some presentation logic is needed there is to take the result of the rendering (a String containing the SVG) and show it somewhere with the ending .svg (for Adobe SVG Plugins sake). As the parts for configuration and direct selection of the Topic etc.(my navigation) is not needed if combined with the "text" > presentation. We just need to write some little code that takes the SVG String and writes it out. > > In my opinion the main problem with integrating it is, that panckoucke works with an abstraction layer and wraps the TopicMaps etc with its own classes (e.g. TopicMapReference etc.). Moreover the api is designed in a way, that there is no approved way to add a provider to the StoreManager (the management component for TopicMaps and Providers). Because > of this, we cant just use an abstractor with the TopicMap held inside the TM4Web classes. We could A) change the API or B) find a way around it. I am for B at the moment (but thats maybe because I already have a soultion in mind [see later]:). > Panckoucke has the context for the general configuration. My app works with the panckoucke context and retrieves a specified TopicMap, Abstractor and Renderer from the context (this is done by ids and the baseLocatorAdress). So the only thing we have to do in terms of configuration is to specify ids for Renderer and Abstractor and the baseLocatorAdress > for the TopicMap (the actions expect ServletContext attributes with the names TOPICMAP, RENDERER and ABSTRACTOR). I think in doing it this way, everything is decoupled enough so that both parts can still be used seperately. > > For sharing the providers, I experimented with a JNDI Wrapper. The idea was to export a Provider though JNDI. The wrapper looks up the shared provider and calls its appropriate methods. I did this for beeing able to share the same TopicMaps between two different webapps. But I think we could also use it here ?! > > I am eager to learn what kind of ideas you have about this problems! > > > For the checkin, i suggest the following: > > - a folder TopicMapViewer for my demo app > (i would like to keep it out of two reasons, it can be used to play with the panckoucke code and > it is an example of using tm4web with jsp) > - a folder panckoucke with the packages org.tm4j.tm4web.panckoucke [and subpackages] for the > panckoucke related implementations (e.g. the SVG Renderer - this would give use more > seperation, the panckoucke stuff will only be used as a jar file in the struts / velocity app) > - the package org.tm4j.vtl-panckoucke and org.tm4j.vtl-panckoucke.struts for the actions etc. > > > So if you have no major objections, I think the best way to do this is for me to check in everything so that everybody interested can have a look at it. Afterwards we can start implementing the combined app (or whats missing for it). > > Cheers, > Harald > > > Hi Harald, > > > > On Fri, 2003-07-18 at 08:15, Harald Kuhn wrote: > > > Hi Kal, > > > as i finished my this years exams earlier this week, I do now have a bit of spare time to work on the integration of the TopicMapViewer into the TM4Web Project. > > > > > Cool! Glad to have you back...I hope the exams went well. > > > > I'm really happy that you are wiling to contribute to this project > > because there are a lot of cool things to do! > > > > > What are your plans for the TM4Web Project at the moment ? Do you have any wishes, ideas etc, for the integration ? I would like to suggest mergeing the struts / velocity based tm4web module with the now struts and panckoucke based code in order to get graphical and textual navigation and presentation for TopicMaps. > > > > > > > My plans are really just to get it documented and released as soon as > > possible. However I think your proposal of merging the panckoucke > > framework with the is a good idea but I would like to be sure that the > > "vanilla" TM4J velocity integration also remains. I think that it should > > be possible to do this by extending the configuration file syntax a > > little. Currently the configuration file specifies a template to use to > > render a topic or all topics of a specific type. We could extend it to > > specify a panckoucke abstractor to be used as well... would that fit > > with the design of your package ? > > > > > I followed your suggestion and started porting the prototypes "buisness logic" to struts. It already works relatively well (if one ignores the fact that in order to change the renderer, one sometimes has to restart the application :) ). > > > I created a Servlet which uses the new PanckouckeContext to create and hold the panckoucke related configuration (TopicMaps, Abstractors, Renderers) as well as a couple of struts actions. > > > > > > > Cool - do you think it would be easy to integrate this directly into the > > existing Velocity servlet in TM4Web ? > > > > > > > What do you think would be the best place for the code and the demo application inside the TM4Web directory ? > > > I would like to suggest using the java package org.tm4j.tm4web.graphical for the java code and maybe a new directory for the TopicMapViewer. I think the TopicMapViewer is interesting enough (in terms of technologie demo and experimental development platform) to keep it. > > > > That sounds good to me. Perhaps the Velocity code can go into the > > velocity subdirectory...there is a package org.tm4j.vtl for the Velocity > > stuff (which is where the current Velocity servlet is) and > > org.tm4j.vtl.struts for the Struts forms and actions. If we are going to > > integrate the code you have then I think it makes sense to match that > > layout. Perhaps org.tm4j.vtl-panckoucke and > > org.tm4j.vtl-panckoucke.struts ? > > > > Well, whatever you decide is fine - moving classes around is quite easy > > with Eclipse :) > > > > Cheers, > > > > Kal > > > > > > > ______________________________________________________________________________ > Wo gibt es den besten Spam-Schutz? Computerbild 15-03 sagt bei > WEB.DE FreeMail - Deutschlands beste E-Mail - http://s.web.de/?mc=021123 -- Christoph Froehlich <cf...@fo...> |
|
From: Harald K. <har...@we...> - 2003-07-22 10:07:02
|
Hi Kal, thanks, the exams were ok! Eclipse seems to be the tool of coice for the whole tm4j team :). The prototype works with struts / jsp so there is no velocity support at the moment. This is no problem however, because most of the work is anyway done in the actions etc. The SVG (for example) is generated inside the renderer, so the only place some presentation logic is needed there is to take the result of the rendering (a String containing the SVG) and show it somewhere with the ending .svg (for Adobe SVG Plugins sake). As the parts for configuration and direct selection of the Topic etc.(my navigation) is not needed if combined with the "text" presentation. We just need to write some little code that takes the SVG String and writes it out. In my opinion the main problem with integrating it is, that panckoucke works with an abstraction layer and wraps the TopicMaps etc with its own classes (e.g. TopicMapReference etc.). Moreover the api is designed in a way, that there is no approved way to add a provider to the StoreManager (the management component for TopicMaps and Providers). Because of this, we cant just use an abstractor with the TopicMap held inside the TM4Web classes. We could A) change the API or B) find a way around it. I am for B at the moment (but thats maybe because I already have a soultion in mind [see later]:). Panckoucke has the context for the general configuration. My app works with the panckoucke context and retrieves a specified TopicMap, Abstractor and Renderer from the context (this is done by ids and the baseLocatorAdress). So the only thing we have to do in terms of configuration is to specify ids for Renderer and Abstractor and the baseLocatorAdress for the TopicMap (the actions expect ServletContext attributes with the names TOPICMAP, RENDERER and ABSTRACTOR). I think in doing it this way, everything is decoupled enough so that both parts can still be used seperately. For sharing the providers, I experimented with a JNDI Wrapper. The idea was to export a Provider though JNDI. The wrapper looks up the shared provider and calls its appropriate methods. I did this for beeing able to share the same TopicMaps between two different webapps. But I think we could also use it here ?! I am eager to learn what kind of ideas you have about this problems! For the checkin, i suggest the following: - a folder TopicMapViewer for my demo app (i would like to keep it out of two reasons, it can be used to play with the panckoucke code and it is an example of using tm4web with jsp) - a folder panckoucke with the packages org.tm4j.tm4web.panckoucke [and subpackages] for the panckoucke related implementations (e.g. the SVG Renderer - this would give use more seperation, the panckoucke stuff will only be used as a jar file in the struts / velocity app) - the package org.tm4j.vtl-panckoucke and org.tm4j.vtl-panckoucke.struts for the actions etc. So if you have no major objections, I think the best way to do this is for me to check in everything so that everybody interested can have a look at it. Afterwards we can start implementing the combined app (or whats missing for it). Cheers, Harald > Hi Harald, > > On Fri, 2003-07-18 at 08:15, Harald Kuhn wrote: > > Hi Kal, > > as i finished my this years exams earlier this week, I do now have a bit of spare time to work on the integration of the TopicMapViewer into the TM4Web Project. > > > Cool! Glad to have you back...I hope the exams went well. > > I'm really happy that you are wiling to contribute to this project > because there are a lot of cool things to do! > > > What are your plans for the TM4Web Project at the moment ? Do you have any wishes, ideas etc, for the integration ? I would like to suggest mergeing the struts / velocity based tm4web module with the now struts and panckoucke based code in order to get graphical and textual navigation and presentation for TopicMaps. > > > > My plans are really just to get it documented and released as soon as > possible. However I think your proposal of merging the panckoucke > framework with the is a good idea but I would like to be sure that the > "vanilla" TM4J velocity integration also remains. I think that it should > be possible to do this by extending the configuration file syntax a > little. Currently the configuration file specifies a template to use to > render a topic or all topics of a specific type. We could extend it to > specify a panckoucke abstractor to be used as well... would that fit > with the design of your package ? > > > I followed your suggestion and started porting the prototypes "buisness logic" to struts. It already works relatively well (if one ignores the fact that in order to change the renderer, one sometimes has to restart the application :) ). > > I created a Servlet which uses the new PanckouckeContext to create and hold the panckoucke related configuration (TopicMaps, Abstractors, Renderers) as well as a couple of struts actions. > > > > Cool - do you think it would be easy to integrate this directly into the > existing Velocity servlet in TM4Web ? > > > > What do you think would be the best place for the code and the demo application inside the TM4Web directory ? > > I would like to suggest using the java package org.tm4j.tm4web.graphical for the java code and maybe a new directory for the TopicMapViewer. I think the TopicMapViewer is interesting enough (in terms of technologie demo and experimental development platform) to keep it. > > That sounds good to me. Perhaps the Velocity code can go into the > velocity subdirectory...there is a package org.tm4j.vtl for the Velocity > stuff (which is where the current Velocity servlet is) and > org.tm4j.vtl.struts for the Struts forms and actions. If we are going to > integrate the code you have then I think it makes sense to match that > layout. Perhaps org.tm4j.vtl-panckoucke and > org.tm4j.vtl-panckoucke.struts ? > > Well, whatever you decide is fine - moving classes around is quite easy > with Eclipse :) > > Cheers, > > Kal > > ______________________________________________________________________________ Wo gibt es den besten Spam-Schutz? Computerbild 15-03 sagt bei WEB.DE FreeMail - Deutschlands beste E-Mail - http://s.web.de/?mc=021123 |
|
From: Harald K. <har...@we...> - 2003-07-17 22:23:25
|
Hi Kal, as i finished my this years exams earlier this week, I do now have a bit of spare time to work on the integration of the TopicMapViewer into the TM4Web Project. What are your plans for the TM4Web Project at the moment ? Do you have any wishes, ideas etc, for the integration ? I would like to suggest mergeing the struts / velocity based tm4web module with the now struts and panckoucke based code in order to get graphical and textual navigation and presentation for TopicMaps. I followed your suggestion and started porting the prototypes "buisness logic" to struts. It already works relatively well (if one ignores the fact that in order to change the renderer, one sometimes has to restart the application :) ). I created a Servlet which uses the new PanckouckeContext to create and hold the panckoucke related configuration (TopicMaps, Abstractors, Renderers) as well as a couple of struts actions. What do you think would be the best place for the code and the demo application inside the TM4Web directory ? I would like to suggest using the java package org.tm4j.tm4web.graphical for the java code and maybe a new directory for the TopicMapViewer. I think the TopicMapViewer is interesting enough (in terms of technologie demo and experimental development platform) to keep it. Cheers , Harald ______________________________________________________________________________ ComputerBild (15-03) empfiehlt den besten Spam-Schutz: WEB.DE FreeMail - Deutschlands beste E-Mail - http://s.web.de/?mc=021125 |
|
From: Christoph F. <cf...@fo...> - 2003-06-28 09:31:19
|
Hi yesterday, I added a new renderer and a new abstractor to the tmnav/panckoucke cvs. The abstractor is called ExtendedAbstractor and gives you a very detailed model for a given Topic. What is still missing in tha model is information about names and reification. Also missing is documentation but you can view the model with the HypergraphRenderer in order to get an idea of its shape. Furthermore the ExtendedAbstractor currently only supports Topics. At least, I want to add support for association. The renderer displays the results of the extendend abstractor in a very strict way. There is still work to be done on how association are grouped and displayed together, as well as on the overall appearance. Bye c |
|
From: Christoph F. <cf...@fo...> - 2003-06-09 17:22:35
|
Hi Harald Am Fre, 2003-06-06 um 21.06 schrieb Harald Kuhn: > Hi Christoph, > > first of all, sorry for my somewhat unclear question about testing. I > wanted to ask wether anybody has any experiance with testing xml > parsers. Whith code generation I meant the generation of xml input for > the parser(here Digester), so that it can be compared with the created > objects. Sorry. No big ideas. You might want to use a StringReader in order to maintain the xml in your code. > > > About the howto: I think i will just start with writing a little bit > of text about how to create a context, which we can extend later. > However, it would be most helpfull, if you could send me the xsl > stylesheets you used with the other howtos. I just used the docbook-xsl-stylesheets. You find them here: http://docbook.sourceforge.net/projects/xsl/ > > About the attributes: > > 1. The notation attribute is implemented with xtm as default (so if > there is no notation attribute, xtm is expected as the notation of the > file). I just forgot to add this into the DTD. > > 2. I thought about the version attribute again and i think (if nobody > objects) that we should remove it from the context. I would like to > comment it out however, so if we get some trouble with different > versions (or if we make some major changes in the dtd), we can easily > add it again. > > 3. This is a bit more complicated because if the attibutes is not > there and the dtd is not available, a NullPointerException will occur. > However, I can change it, if you really think this to be important. > I saw you already committed. Great. > What kind of Renderer do you work on ? Is there already anything > usable ? I think I will be able to commit an early version the next days. It is a renderer which show you the charactersitics of a topic in a very detailed way. It will use Tables and Text-Labels. Not fancy, but useful. At least, I hope so Bye c > > Greetings > Harald > > > Hi Harald > > > > great, that you got through with it. > > > > I browsed the documentation (which is very readable indeed) and > stumbled > > over three attributes, which I would prefer to set to IMPLIED > instead of > > REQUIRED. > > > > 1. > > First is the "notation"-Attribute of the loadmap-Tag. I would > suggest to > > make "xtm" the default value. > > > > 2. > > Second is the "version"-Atribute of the panckoucke-Tag. I'm still > not > > completely convinced, that we need it, but if we do, we should > describe > > - what it serves for, > > - how panckoucke reacts if incorrect values are supplied > > - and finally how to supply correct values (notation, > > backwards-compability to previous panckoucke-version, etc...). > > > > Furthermore I would suggest to make it IMPLIED. If no version is > > supplied, the ContextReader should assume that it is the correct > version > > and attempt to parse it. If it then breaks, it breaks. > > > > 3. > > The properties-Attribute of the provider-Attribute should default to > > "Empty". Just to make writing the context more convenient. > > > > > > An HowTo for the context would be most desirable. Unfortunately I > have > > some other things to do (real-world-things) and I'm currently > working on > > a third renderer for tmnav, so time is a bit spare and I can't > promise > > that I will find the time to contribute. But I will try. > > > > > > Sorry, but I don't understand your final question about the > XML-Parsers. > > What do you want to test? What is meant by XML code generation? > > > > > > Bye > > c > > > > > > > > > > > > Am Don, 2003-06-05 um 12.51 schrieb Harald Kuhn: > > > Hi all, > > > > > > i am nearly finished with the changes Christop and i wrote about. > I also started writing some documentation about the context and the > DTD. > > > I used a sourceforge project called DTDDoc to auto generate a > documentation for the panckoucke DTD which I placed into the doc > folder of panckoucke. Please have a look at it and tell me wether you > find it useful. > > > > > > I think we should probably also write an HowTo for the context > (maybe we should coordinate ourself on this Christoph ?). > > > > > > Does anybody have any experience with testing XML Parsers > (especially the XML code generation)? > > > > > > Cheers, > > > > > > Harald > > > ________________________________________________________________ > > > Viren? Wir wissen nicht was Ihr Arzt empfiehlt. Wir empfehlen den > > > WEB.DE Virencheck! http://freemail.web.de/features/?mc=021159 > > > > _______________________________________________________________________ > > > Das WEB.DE Zertifikat zur Pruefung digitaler Unterschriften gibts > bei: > > > http://trust.web.de/root.sql > > -- > > Christoph Froehlich <cf...@fo...> > > > > > ____________________________________________________________________________ > Jetzt bei WEB.DE FreeMail anmelden = 1qm Regenwald schuetzen! Helfen > Sie mit! Nutzen Sie den Serien-Testsieger. > http://user.web.de/Regenwald -- Christoph Froehlich <cf...@fo...> |
|
From: Martin S. <hu...@we...> - 2003-06-08 20:54:16
|
Hi Harald, I looked at the context implementation and it seems a great work! I think it will save me a lot of work. The DTD documentation is fine to read, but a HowTo would be a nice addition. I think the version tag is not neccessary, if the xml-file is validated against the DTD. Bye Martin Harald Kuhn wrote: > Hi all, > > i am nearly finished with the changes Christop and i wrote about. I also started writing some documentation about the context and the DTD. > I used a sourceforge project called DTDDoc to auto generate a documentation for the panckoucke DTD which I placed into the doc folder of panckoucke. Please have a look at it and tell me wether you find it useful. > > I think we should probably also write an HowTo for the context (maybe we should coordinate ourself on this Christoph ?). > > Does anybody have any experience with testing XML Parsers (especially the XML code generation)? > > Cheers, > > Harald > ________________________________________________________________ > Viren? Wir wissen nicht was Ihr Arzt empfiehlt. Wir empfehlen den > WEB.DE Virencheck! http://freemail.web.de/features/?mc=021159 > _______________________________________________________________________ > Das WEB.DE Zertifikat zur Pruefung digitaler Unterschriften gibts bei: > http://trust.web.de/root.sql |
|
From: Harald K. <har...@we...> - 2003-06-06 19:06:27
|
Hi Christoph, first of all, sorry for my somewhat unclear question about testing. I wanted to ask wether anybody has any experiance with testing xml parsers. Whith code generation I meant the generation of xml input for the parser(here Digester), so that it can be compared with the created objects. About the howto: I think i will just start with writing a little bit of text about how to create a context, which we can extend later. However, it would be most helpfull, if you could send me the xsl stylesheets you used with the other howtos. About the attributes: 1. The notation attribute is implemented with xtm as default (so if there is no notation attribute, xtm is expected as the notation of the file). I just forgot to add this into the DTD. 2. I thought about the version attribute again and i think (if nobody objects) that we should remove it from the context. I would like to comment it out however, so if we get some trouble with different versions (or if we make some major changes in the dtd), we can easily add it again. 3. This is a bit more complicated because if the attibutes is not there and the dtd is not available, a NullPointerException will occur. However, I can change it, if you really think this to be important. What kind of Renderer do you work on ? Is there already anything usable ? Greetings Harald > Hi Harald > > great, that you got through with it. > > I browsed the documentation (which is very readable indeed) and stumbled > over three attributes, which I would prefer to set to IMPLIED instead of > REQUIRED. > > 1. > First is the "notation"-Attribute of the loadmap-Tag. I would suggest to > make "xtm" the default value. > > 2. > Second is the "version"-Atribute of the panckoucke-Tag. I'm still not > completely convinced, that we need it, but if we do, we should describe > - what it serves for, > - how panckoucke reacts if incorrect values are supplied > - and finally how to supply correct values (notation, > backwards-compability to previous panckoucke-version, etc...). > > Furthermore I would suggest to make it IMPLIED. If no version is > supplied, the ContextReader should assume that it is the correct version > and attempt to parse it. If it then breaks, it breaks. > > 3. > The properties-Attribute of the provider-Attribute should default to > "Empty". Just to make writing the context more convenient. > > > An HowTo for the context would be most desirable. Unfortunately I have > some other things to do (real-world-things) and I'm currently working on > a third renderer for tmnav, so time is a bit spare and I can't promise > that I will find the time to contribute. But I will try. > > > Sorry, but I don't understand your final question about the XML-Parsers. > What do you want to test? What is meant by XML code generation? > > > Bye > c > > > > > > Am Don, 2003-06-05 um 12.51 schrieb Harald Kuhn: > > Hi all, > > > > i am nearly finished with the changes Christop and i wrote about. I also started writing some documentation about the context and the DTD. > > I used a sourceforge project called DTDDoc to auto generate a documentation for the panckoucke DTD which I placed into the doc folder of panckoucke. Please have a look at it and tell me wether you find it useful. > > > > I think we should probably also write an HowTo for the context (maybe we should coordinate ourself on this Christoph ?). > > > > Does anybody have any experience with testing XML Parsers (especially the XML code generation)? > > > > Cheers, > > > > Harald > > ________________________________________________________________ > > Viren? Wir wissen nicht was Ihr Arzt empfiehlt. Wir empfehlen den > > WEB.DE Virencheck! http://freemail.web.de/features/?mc=021159 > > _______________________________________________________________________ > > Das WEB.DE Zertifikat zur Pruefung digitaler Unterschriften gibts bei: > > http://trust.web.de/root.sql > -- > Christoph Froehlich <cf...@fo...> > ____________________________________________________________________________ Jetzt bei WEB.DE FreeMail anmelden = 1qm Regenwald schuetzen! Helfen Sie mit! Nutzen Sie den Serien-Testsieger. http://user.web.de/Regenwald |
|
From: Christoph F. <cf...@fo...> - 2003-06-06 12:15:55
|
Hi Harald great, that you got through with it. I browsed the documentation (which is very readable indeed) and stumbled over three attributes, which I would prefer to set to IMPLIED instead of REQUIRED. 1. First is the "notation"-Attribute of the loadmap-Tag. I would suggest to make "xtm" the default value. 2. Second is the "version"-Atribute of the panckoucke-Tag. I'm still not completely convinced, that we need it, but if we do, we should describe - what it serves for, - how panckoucke reacts if incorrect values are supplied - and finally how to supply correct values (notation, backwards-compability to previous panckoucke-version, etc...). Furthermore I would suggest to make it IMPLIED. If no version is supplied, the ContextReader should assume that it is the correct version and attempt to parse it. If it then breaks, it breaks. 3. The properties-Attribute of the provider-Attribute should default to "Empty". Just to make writing the context more convenient. An HowTo for the context would be most desirable. Unfortunately I have some other things to do (real-world-things) and I'm currently working on a third renderer for tmnav, so time is a bit spare and I can't promise that I will find the time to contribute. But I will try. Sorry, but I don't understand your final question about the XML-Parsers. What do you want to test? What is meant by XML code generation? Bye c Am Don, 2003-06-05 um 12.51 schrieb Harald Kuhn: > Hi all, > > i am nearly finished with the changes Christop and i wrote about. I also started writing some documentation about the context and the DTD. > I used a sourceforge project called DTDDoc to auto generate a documentation for the panckoucke DTD which I placed into the doc folder of panckoucke. Please have a look at it and tell me wether you find it useful. > > I think we should probably also write an HowTo for the context (maybe we should coordinate ourself on this Christoph ?). > > Does anybody have any experience with testing XML Parsers (especially the XML code generation)? > > Cheers, > > Harald > ________________________________________________________________ > Viren? Wir wissen nicht was Ihr Arzt empfiehlt. Wir empfehlen den > WEB.DE Virencheck! http://freemail.web.de/features/?mc=021159 > _______________________________________________________________________ > Das WEB.DE Zertifikat zur Pruefung digitaler Unterschriften gibts bei: > http://trust.web.de/root.sql -- Christoph Froehlich <cf...@fo...> |
