On 16 May 2000 10:16:58 CDT, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]>  said:
> Rob Walker <[EMAIL PROTECTED]> writes:
> 
> > okay, I will be the curmudgeon (sp?), here....
> 
> That's exactly what I want.  I'd rather figure out any problems now,
> rather than later.
> 
> With respect to the license, I thought of that while I was poking
> around last night.  I'm not sure if this plays nice with the GPL or
> not.  I'll ask the license "lawyers" I know, and perhaps the GNU
> people, but in the worst case, I wouldn't be surprised if the
> sleepycat people would be willing to offer it under the GPL as well as
> the current license (presuming they have the authority to do so).
> We'll see.

The "lawyering" of this would doubtless be of interest with other
projects too.

> Though I'm still reasonably impressed with sleepycat, I did have the
> following further observations as I poked around last night:
> 
>   - The current db release in Debian is 2.7.7.1.c.  It *looks* like
>     maybe this is the current "stable" version, but it's the last of
>     the 2.X line, and the docs on the sleepycat web site are actually
>     describing 3.X, which is the one they *strongly* recommend people
>     download and use.  So maybe 3.X is the current stable version.
> 
>   - Consequently, some of the features described in the wesite docs
>     are only available in 3.X, not 2.X.
> 
>   - It appears the db format has changed in the past, and changed
>     again from 2.X to 3.X, requiring a dump and load to migrate.  This
>     isn't a big deal, but it's somewhat inconvenient.  This might be
>     another argument for starting with 3.X, but it's also an issue
>     that's likely to crop up in the future.  I suspect, though, that
>     we may be able to handle this internally in gnucash, without
>     bothering the user, but I'm not positive of that.

Debian's release of libdb2 comes with "db_dump185", which is rather
suggestive of a past migration.

I suspect this won't be a _huge_ issue.

>   - The db_dump and db_load programs (that use the text format), don't
>     handle db's with custom sort orders (for btree db's), etc.  So for
>     some db's you have to take the source to db_load and write your
>     own that uses he "right" put() function with the right custom
>     procedures (basically the same put() that you use in your app).

If we used a customized sort order, one of the early utilities ought
to be a custom dump/load, so I don't see this as an immense problem.

>   - Finally, as compared to using something like scheme forms or xml,
>     the text output format used by their db_dump program may not be as
>     user friendly as we'd like.  Though we could perhaps copy/paste
>     their db_dump/load code (and as mentioned above, we may need to),
>     and make the format as user friendly as we like.

I did a bit of fiddling around with db_dump and db_load last night;
it is, indeed, a tad less directly "friendly" than one might wish for.

That comes directly out of the fact that dblib supports somewhat
structured data, as opposed to the traditional "raw hash tables."

The format isn't downright nasty (well, if you forget the -d flag,
it looks pretty nasty...), and is certainly a whole lot better than
fighting with a binary format.

An interesting contrast may be taken with CDB, the "constant database,"
which is largely a read-only format.  It has a slightly friendlier 
data format, albeit one that still mandates a quite strict format to
the input.

[Entertaining utility of the month:  Bun.  It uses the CDB format for
storage, and essentially replicates cpio/tar's functionality, albeit
sans compression.  The cool part is that since it uses a well-specified
"hash table" format, it is _trivial_ to write programs to walk through
data files and look at what's in them.  I don't think tar or cpio are
particularly easy to hack around with...]
--
Rules of the Evil Overlord #210. "All guest-quarters will be bugged
and monitored so that I can keep track of what the visitors I have for
some reason allowed to roam about my fortress are actually plotting."
<http://www.eviloverlord.com/>
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/lsf.html>

Reply via email to