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.
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.
- 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).
- 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.
More thoughts?
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
