tinytim-discuss

[tinyTiM-discuss] tinyTiM MIO vs. TMAPIX I/O

[Lars H. <he...@se...>]

Hi all,

I wonder if I should drop tinyTiM MIO in the near future.

I added tinyTiM's JSON Topic Maps writer and the XTM writers to the
TMAPIX I/O project. That required only 3 - 5 lines code changes since
the writers do not used much of tinyTiM's internal API. The writers in
the TMAPIX I/O project operate upon TMAPI and should therefor work
with any TMAPI 2.0 compatible engine.

The CXTMWriter may require some more work, though; and I did not look
at the CTMWriter yet.

Anyway, if you look closely at tinyTiM's MIO package you'll notice
that it contains very few dependencies at tinyTiM (thanks to the
Streaming API).

I won't remove tinytim.mio tomorrow or next week, I just want to hear
what the users of tinyTiM think about such a step (yes, I mean you
both ;)).

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

Re: [tinyTiM-discuss] tinyTiM MIO vs. TMAPIX I/O

[Hannes N. <h.n...@go...>]

Hi,

As long there is an IO library I don't mind how it is called ;)

Well I guess you won't drop TMAPIX IO and maintaining two similar
libraries is not very efficient.

Long story short: I agree. (which means +1 :) )

regards
Hannes

On Tue, Aug 18, 2009 at 1:54 PM, Lars Heuer<he...@se...> wrote:
> Hi all,
>
> I wonder if I should drop tinyTiM MIO in the near future.
>
> I added tinyTiM's JSON Topic Maps writer and the XTM writers to the
> TMAPIX I/O project. That required only 3 - 5 lines code changes since
> the writers do not used much of tinyTiM's internal API. The writers in
> the TMAPIX I/O project operate upon TMAPI and should therefor work
> with any TMAPI 2.0 compatible engine.
>
> The CXTMWriter may require some more work, though; and I did not look
> at the CTMWriter yet.
>
> Anyway, if you look closely at tinyTiM's MIO package you'll notice
> that it contains very few dependencies at tinyTiM (thanks to the
> Streaming API).
>
> I won't remove tinytim.mio tomorrow or next week, I just want to hear
> what the users of tinyTiM think about such a step (yes, I mean you
> both ;)).
>
> Best regards,
> Lars
> --
> Semagia
> <http://www.semagia.com>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> tinyTiM-discuss mailing list
> tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tinytim-discuss
>



-- 
Onotoa - Simply create your Topic Maps schemas.
http://onotoa.topicmapslab.de

http://www.topicmapslab.de/people/Hannes_Niederhausen

Re: [tinyTiM-discuss] tinyTiM MIO vs. TMAPIX I/O

[Lars H. <he...@se...>]

Hi Hannes,

> Well I guess you won't drop TMAPIX IO and maintaining two similar
> libraries is not very efficient.

Well, I hope TMAPIX I/O is useful for other projects as well. At
least as long as there is no writer/reader interface in TMAPI. Code
which uses TMAPI is ideally independent of any particular engine, so
TMAPIX I/O brings the user closer to that goal than tinyTiM MIO since
tinytim-mio only knows how to setup the TinyTimMapInputHandler but
knows nothing about other engines or TMAPI.

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

Re: [tinyTiM-discuss] tinyTiM MIO vs. TMAPIX I/O

[Hannes N. <h.n...@go...>]

Hi Lars,

> Well, I hope TMAPIX I/O is useful for other projects as well. At
> least as long as there is no writer/reader interface in TMAPI. Code
> which uses TMAPI is ideally independent of any particular engine, so
> TMAPIX I/O brings the user closer to that goal than tinyTiM MIO since
> tinytim-mio only knows how to setup the TinyTimMapInputHandler but
> knows nothing about other engines or TMAPI.

Well I hope so too. It wasn't criticism, when I said you wouldn't drop
TMAPIX I/O.
On the contrary I like the portability of it :)

best regards
Hannes

-- 
Onotoa - Simply create your Topic Maps schemas.
http://onotoa.topicmapslab.de

http://www.topicmapslab.de/people/Hannes_Niederhausen

Re: [tinyTiM-discuss] tinyTiM MIO vs. TMAPIX I/O

[Markus U. <mar...@gm...>]

Lars Heuer schrieb:
> I wonder if I should drop tinyTiM MIO in the near future.
>   
To make the decision process a bit more challenging: *-2*

-- That's what I'd love to say :p, but seriously, while I have yet to
review/compare the individual TMAPIX interfaces, the more generic they
are, the better. A short example how to migrate between the two
libraries in question would be nice (and also an occasion to fill the
wiki). :)
For those who want to support both TMAPI 1.x and 2.x backends, this
shouldn't change much anyway, right? (So, actually, my vote is +1)

Ad astra, Markus

Re: [tinyTiM-discuss] tinyTiM MIO vs. TMAPIX I/O

[Lars H. <he...@se...>]

Hi Markus,

>> I wonder if I should drop tinyTiM MIO in the near future.
>>   
> To make the decision process a bit more challenging: *-2*

:P

> -- That's what I'd love to say :p, but seriously, while I have yet to
> review/compare the individual TMAPIX interfaces, the more generic they
> are, the better. A short example how to migrate between the two
> libraries in question would be nice (and also an occasion to fill the
> wiki). :)

Yes, there will be documentation, of course. The main change will be
the package name, the interfaces / implementations are direct copies
from tinyTiM, so I don't expect that it causes any trouble to migrate.
IIRC you use semagia-mio directly and bypass tinytim-mio anyway,
right? Then you shouldn't recognize any change.

> For those who want to support both TMAPI 1.x and 2.x backends, this
> shouldn't change much anyway, right? (So, actually, my vote is +1)

I didn't test it with tinyTiM 1.5 / TMAPI 1, but it may work. You
can't use the TMAPIX writers, of course. They use the TMAPI 2.0
interfaces.

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

Re: [tinyTiM-discuss] tinyTiM MIO vs. TMAPIX I/O

[Lars H. <he...@se...>]

[...]
>> For those who want to support both TMAPI 1.x and 2.x backends, this
>> shouldn't change much anyway, right? (So, actually, my vote is +1)

> I didn't test it with tinyTiM 1.5 / TMAPI 1, but it may work. You
> can't use the TMAPIX writers, of course. They use the TMAPI 2.0
> interfaces.

Testing revision 85 against tinyTiM 1.5/TMAPI 1.0 caused 714 errors
(running 714 tests) which is a bit, hmmm, suboptimal.

Revision 86 works partially with tinyTiM 1.5: Failures: 62, Errors:
126. The problem is a helper class that uses TMAPI 2.0 to convert XTM
1.0 PSIs to TMDM PSIs.

Anyway, TMAPI 1.0 has no priority for me, so it's unlikely that I put
much effort into fixing the remaining errors. The tinyTiM 1.5 tests
are not executed by default (only Ontopia, tinyTiM 2.x, generic
TMAPI), you can test it with

        ant test-tinytim-1


Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

Re: [tinyTiM-discuss] tinyTiM MIO vs. TMAPIX I/O

[Lars H. <he...@se...>]

[...]
> Anyway, TMAPI 1.0 has no priority for me, so it's unlikely that I put
> much effort into fixing the remaining errors. The tinyTiM 1.5 tests
> are not executed by default (only Ontopia, tinyTiM 2.x, generic
> TMAPI), you can test it with

>         ant test-tinytim-1

Now:
    ant test.tinytim-1

:)

Solving <http://code.google.com/p/tmapix/issues/detail?id=7> should
generate less errors, though.

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>

Re: [tinyTiM-discuss] tinyTiM MIO vs. TMAPIX I/O

[Lars H. <he...@se...>]

[...]
> Solving <http://code.google.com/p/tmapix/issues/detail?id=7> should
> generate less errors, though.

I created a TMAPIX i/o snapshot (0.3.0):
<http://code.google.com/p/tmapix/downloads/list> which contains the
same set of readers as tinyTiM and the XTM 1.0 / 2.0 and JTM writer.

The XTMTopicMapReader / XTM10TopicMapReader have a method to disable /
enable the translation to TMDM (disabled by default). If the user
disables the translation, the readers work with TMAPI 1.0/tinyTiM 1.5
without exceptions.

The tests enable the translation, though. So you'll get the same set
of failures / errors if you try ``ant test.tinytim-1``. But it works
if you don't enable the translation in your app.

Best regards,
Lars
-- 
Semagia 
<http://www.semagia.com>