Marc Britten writes:
> I don't think that throwing out the old code is the way to go, however
> my thoughts with moving to SQL is
>
> a) it should be faster, with a good SQL backend it should improve
> caching etc.
I don't think so. Berkeley DB is fast. Faster than an SQL backend simply
because it does a lot less. Berkeley DB is able to do caching shared among
processes and files. Caching is not tunable at present (except on the word
database) and some reasonable amount of work would dramaticaly improve the
situation.
> b) easier to integrate the same db w/ other tools, no need to port
> something w/ SQL to a different backend.
I agree on that, although this may not be the most beneficial effect.
We really want a SQL database to be able to redesign the data structures
used by htdig. We need to redesign the data structures of htdig to be
able to handle million pages and hundred of thousands servers. Although
this may not be needed for most htdig users, many of them want to index
100 to 500 servers and this proves quite impractical with htdig current
implementation.
> don't get me wrong I don't want to scrap the other backend, if people
> are happy w/ it as is, so be it, however people on cosource seem to be
> willing to give 300 dollars for MySQL capabilities by its self.
:-)
> right now my thoughts are to keep 2 different sets of files in the
> source tree, one with Berkeley DB one using the abstraction layer for
> SQL. this will keep the files clean of a bunch of ifdefs n whatnot, and
> 10 or however many extra source files shouldn't brake anybody's storage
> budget.
IMHO, this is a bad idea, as explained in previous mails.
--
Loic Dachary
24 av Secretan
75019 Paris
Tel: 33 1 42 45 09 16
e-mail: [EMAIL PROTECTED]
URL: http://www.senga.org/
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
