You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
(30) |
May
(4) |
Jun
(19) |
Jul
(36) |
Aug
(21) |
Sep
(10) |
Oct
(18) |
Nov
(43) |
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(5) |
Feb
(18) |
Mar
(6) |
Apr
|
May
|
Jun
(6) |
Jul
(21) |
Aug
(47) |
Sep
(3) |
Oct
|
Nov
(5) |
Dec
|
2010 |
Jan
(8) |
Feb
|
Mar
(5) |
Apr
(2) |
May
|
Jun
(14) |
Jul
(2) |
Aug
|
Sep
(4) |
Oct
(4) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
From: Lars H. <he...@se...> - 2008-04-17 17:04:48
|
Hi Stefan, [...] > No problem, just commit your code to the svn and i'll play with it and > write some more tests and if we both are happy lets release. Yep! :)) [...] > What are these 2 other tm engines and the MIO project? confidential? No, nothing confidential :) One TM engine is the infamous Mappa project (Python) <http://mappa.semagia.com/> and the other is a Java Topic Maps engine with similar but different goals as tinyTiM. ;) It holds also everything in-memory but is committed to TMDM and provides intentionally no TMAPI support. It provides no factory methods like TMAPI but the user creates the Topic Maps construct via simple constructors (almost no interfaces are exposed). While the Topic Maps construct is not attached to a topic map, the user can do everything with it. Once it is attached, the engine won't let the user create invalid topic maps. The topic map is always in a valid state. So far the theory ;) MIO is the streaming Topic Maps API I suggested for TMAPI. Funnily, all three projects are the reason for the tinyTiM redesign. All projects support TMAPI somehow and I used always tinyTiM for test cases etc. That was also the reason why I came to the limits of it. TM4J is no alternative; I just need a reliable TMAPI-compatible Topic Maps engine. Hopefully, tinyTiM is the solution :) >>> Dunno if we should put these Junit tests to the TMAPI Test-suite or put >>> it in the tinyTIM SVN [...] >> I'd propose to keep them separated. We include a test-runner for these >> but the tests itself should not be imported into the SVN. >> > hmm, where do you think we should develop the test suite? i think the > tinyTIM svn might be the right place? Maybe I misunderstood you. Of course, we put all test cases into the SVN. But I understood that you suggested to import the tests from the TMAPI project into the SVN. I see no reason for it, since the TMAPI test cases are available as lib from the TMAPI project. Mirroring the TMAPI CVS makes no sense, but the tinyTiM test cases should go into the SVN. [...] >> Attached. Sorry. > Thanks no problem, the html is enough, i'm doing a screenshot for my > history book myself. No problem if you want to load it up. You can delete it afterwards and the redirection stays again. If you load it up, you'll have the 'original' http://tinytim.sf.net/ URL in your browser's window. :) Best regards, Lars -- http://www.semagia.com |
From: Stefan L. <li...@ap...> - 2008-04-17 16:31:07
|
Hi Lars, > I don't mind, if you think it's nice to keep the TMAPI / tinyTiM > versions aligned. Let's call it "1.5". OK >> OK, so we need Junit Tests for the actual Version that fail and work on >> tinyTIM 1.X >> AFAIK tinyTIM 1.0 SP1 passes all TMAPI Junit tests. >> > > Yes, but tinyTiM has some other problems. The TMAPI tests are > sufficient to test all aspects of a Topic Maps engine. > > I submit some unit test but we can create more. Tests do no harm. ;) > dito, i'm totally into test-driven development. > Anyway, I think I won't have much time to work intensively on tinyTiM > in the next weeks since I've to finish together with Gab and Dmitry > the next CTM draft. Additionally, I have two other Topic Maps engines > in the pipeline and I like to finish / publish the MIO project. The > re-creation of tinyTiM was an accident / not planned. ;) > No problem, just commit your code to the svn and i'll play with it and write some more tests and if we both are happy lets release. What are these 2 other tm engines and the MIO project? confidential? >> Dunno if we should put these Junit tests to the TMAPI Test-suite or put >> it in the tinyTIM SVN >> > > I'd propose to keep them separated. We include a test-runner for these > but the tests itself should not be imported into the SVN. > hmm, where do you think we should develop the test suite? i think the tinyTIM svn might be the right place? we should not put it in the release. >> What about >> http://tinytim.sourceforge.net/ >> it now links to the wiki, is the old page still available? its ok to put >> it down, but i need a clear screenshot before closing this site. >> > > Attached. Sorry. Thanks no problem, the html is enough, i'm doing a screenshot for my history book myself. Stefan |
From: Lars H. <he...@se...> - 2008-04-17 15:59:03
|
[...] > The TMAPI tests are sufficient to test all aspects of a Topic Maps > engine. Obviously, there is a "NOT" missing: "[...] are not sufficient [...]" Best regards, Lars -- http://www.semagia.com |
From: Lars H. <he...@se...> - 2008-04-17 15:37:57
|
Hi Stefan, [...] >> propose to release that code as tinyTiM 2.0 alpha. And then fix bugs. [...] > hmm, we should save the version 2.0 for the TMAPI 2.0 implementation. I don't mind, if you think it's nice to keep the TMAPI / tinyTiM versions aligned. Let's call it "1.5". [...] > OK, so we need Junit Tests for the actual Version that fail and work on > tinyTIM 1.X > AFAIK tinyTIM 1.0 SP1 passes all TMAPI Junit tests. Yes, but tinyTiM has some other problems. The TMAPI tests are sufficient to test all aspects of a Topic Maps engine. I submit some unit test but we can create more. Tests do no harm. ;) Anyway, I think I won't have much time to work intensively on tinyTiM in the next weeks since I've to finish together with Gab and Dmitry the next CTM draft. Additionally, I have two other Topic Maps engines in the pipeline and I like to finish / publish the MIO project. The re-creation of tinyTiM was an accident / not planned. ;) > Dunno if we should put these Junit tests to the TMAPI Test-suite or put > it in the tinyTIM SVN I'd propose to keep them separated. We include a test-runner for these but the tests itself should not be imported into the SVN. [...] >> I hope that TMAPI 2.0 will ease the development of tinyTiM reasonably >> since we can remove some of the internal interfaces and remove some >> casts / hacks here and there etc. > Sorry for those :-) but they where necessary for xtm4xmldb, which was > build ontop of some tinyTIM classes. Hmm... no I meant interfaces like "Typed" or "Reifiable" I created for the new codebase. > I think i have to close the XMT4XMLDB project ;-( although there are > some running projects out there using xtm4xmldb ... Hmmm... your codebase is still untouched in the CVS, so there is no reason to kill XTM4XMLDB, I think. > What about > http://tinytim.sourceforge.net/ > it now links to the wiki, is the old page still available? its ok to put > it down, but i need a clear screenshot before closing this site. Attached. Sorry. I deleted the "docs" directory by mistake but fortunately it is in the CVS. I made a backup of the "index.html". You can upload it again if you want but then the redirection to the Wiki does not work anymore (if SF sees a "index.php" and a "index.html" it prefers the ".html"). Best regards, Lars -- http://www.semagia.com |
From: Stefan L. <li...@ap...> - 2008-04-17 15:05:16
|
Hi, > I like to propose the following roadmap for tinyTiM: I think I'll > have the next tinyTiM version ready in the next few days. I like to > propose to release that code as tinyTiM 2.0 alpha. And then fix bugs. > I think 2.0 is reasonable since it is a new code base. If we do not > encounter any bugs we can release 2.0 officially within the next > weeks. Note, that 2.0 is TMAPI 1.0 compatible but more or less TMDM > ready. Even if it would be possible to expose the TMDM features to the > users, I don't think we should do it now but wait for TMAPI 2.0. > hmm, we should save the version 2.0 for the TMAPI 2.0 implementation. So it might be tinyTIM 1.5 or maybe tinyTIM X or tinyTIM 1.X to represent the codebase change. > I think releasing tinyTiM 2.0 *now* is reasonable since it should be > more standard compliant (i.e. merging, duplicate suppression) than the > current release and / or the CVS version. > OK, so we need Junit Tests for the actual Version that fail and work on tinyTIM 1.X AFAIK tinyTIM 1.0 SP1 passes all TMAPI Junit tests. Dunno if we should put these Junit tests to the TMAPI Test-suite or put it in the tinyTIM SVN > Once the TMAPI project has released some TMAPI 2.0 interfaces, we > create a 3.0 branch, implement the TMAPI 2.0 interfaces and we expose > the TMDM features to the user (these are hidden if the user uses TMAPI > 1.0). > As said above, lets save 2.0 for TMAPI 2.0 > I hope that TMAPI 2.0 will ease the development of tinyTiM reasonably > since we can remove some of the internal interfaces and remove some > casts / hacks here and there etc. > Sorry for those :-) but they where necessary for xtm4xmldb, which was build ontop of some tinyTIM classes. I think i have to close the XMT4XMLDB project ;-( although there are some running projects out there using xtm4xmldb ... What about http://tinytim.sourceforge.net/ it now links to the wiki, is the old page still available? its ok to put it down, but i need a clear screenshot before closing this site. Stefan |
From: Lars H. <he...@se...> - 2008-04-17 14:22:57
|
Hi, I like to propose the following roadmap for tinyTiM: I think I'll have the next tinyTiM version ready in the next few days. I like to propose to release that code as tinyTiM 2.0 alpha. And then fix bugs. I think 2.0 is reasonable since it is a new code base. If we do not encounter any bugs we can release 2.0 officially within the next weeks. Note, that 2.0 is TMAPI 1.0 compatible but more or less TMDM ready. Even if it would be possible to expose the TMDM features to the users, I don't think we should do it now but wait for TMAPI 2.0. I think releasing tinyTiM 2.0 *now* is reasonable since it should be more standard compliant (i.e. merging, duplicate suppression) than the current release and / or the CVS version. Once the TMAPI project has released some TMAPI 2.0 interfaces, we create a 3.0 branch, implement the TMAPI 2.0 interfaces and we expose the TMDM features to the user (these are hidden if the user uses TMAPI 1.0). I hope that TMAPI 2.0 will ease the development of tinyTiM reasonably since we can remove some of the internal interfaces and remove some casts / hacks here and there etc. Best regards, Lars -- http://www.semagia.com |
From: Lars H. <he...@se...> - 2008-04-17 12:22:55
|
Hi Stefan, [...] > On one hand you can modify your topicmap with the direct java calls, but > you are also able to modify it via the underlying untyped tmapi calls. If this approach is generic enough (does not depend on tinyTiM, but on TMAPI), you should put it into the TMAPI-Utils package, I think. So every Topic Maps engine which supports TMAPI could use it. What do you think? Best regards, Lars -- http://www.semagia.com |
From: Stefan L. <li...@ap...> - 2008-04-17 10:29:08
|
Hi Lars, if we are working on tinyTIM 2.0 to adapt TMAPI 2.0 i plan to implement a new feature. I'm working with XmlBeans for a very long time now and it is a great help when working with XML. I want this stuff also for topic maps, so i have Java Types for my TopicMap types with getters and setters for the information items. On one hand you can modify your topicmap with the direct java calls, but you are also able to modify it via the underlying untyped tmapi calls. I thought about this earlier in 2006-10 when reading Lars Marius Blog about TMRA2006 See my comments below http://www.garshol.priv.no/blog/74.html <http://www.garshol.priv.no/blog/74.html> The original approach of TMObjects is quite a bit different , its like hibernate for TM. see http://www.networkedplanet.com/ontopic/2007/07/topic_map_objects_research_pap.html <http://www.networkedplanet.com/ontopic/2007/07/topic_map_objects_research_pap.html> |
From: Stefan L. <li...@ap...> - 2008-04-16 16:38:41
|
Hi Lars, I got your response, but not my mail to the list, lets wait if i get this message Lars Heuer wrote: > Hi Stefan, > > Seems to work... :) > > Best regards, > Lars > |
From: Lars H. <he...@se...> - 2008-04-16 15:35:03
|
Hi Stefan, Seems to work... :) Best regards, Lars -- http://www.semagia.com |
From: Stefan L. <li...@ap...> - 2008-04-16 15:14:58
|
sdfsdfsdfsd |