Re: [Kionjb-devel] Re: Bringing kionjb up to libnjb1.3

[Shaun J. <sja...@gm...>]

I condone and in fact suggested the fork; it is the result of a fairly
fundamental technical difference. My first generation NJB (USB 1.1) is
definitely I/O bound. I used libsqlite because it simplified the code
greatly -- versions prior to 0.1.0 didn't use libsqlite, and it was
messy -- and added non-volatility to the cached track list inherently.
Steup (the maintainer of -st) had a later NJB (USB 2.0). He removed
the use of libsqlite and the initial caching of tracks was apparently
much faster for him. It does not maintain a local cache on disk
though, so further operations are not any faster, whereas when reading
from libsqlite they are near instantaneous.

We discussed ways of merging the two, but it is a significant amount
of work that neither of us has time for. The best approach, we found,
was doing the initial read directly to memory, to display the results
quickly, and then writing the information to disk using libsqlite in
the background. Further results would come from the libsqlite disk
cache.

If you are interested, I would very much like my 0.1.6 branch ported
to libnjb 1.2/1.3 as well.

Contributing to code distributed in tarballs is not more difficult
than CVS, assuming the author keeps his tarballs up to date with CVS;
authors that do not release tarballs annoy me some. Diff your
improvements against the original tarball and send the patch upstream
for incorporation. Classic open source.

Cheers, and thanks for your interest and work,
Shaun


On Sat, 08 Jan 2005 16:47:16 -0800, ace jones <ac...@ho...> wrote:
> Hi, Shaun.  I noticed there was a fork.  Are there plans to merge the
> forks back at all?  Or is there a fundamental split of some sort between
> the two?
> 
> I have 0.2.2-st ported over to the new library and compiling.  Still
> working out some of the kinks.
> 
> </Ace>
> 
> P/S Having the code in CVS also makes it easy for other to contribute!