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.
b) easier to integrate the same db w/ other tools, no need to port
something w/ SQL to a different backend.
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.
Andrew Scherpbier wrote:
>
> I think that this is the right way to approach this subject: Why do
> people want to use a SQL backend?
> Please correct me if I am wrong, but it seems to me that some folks just
> want SQL because they a) are familiar with it or b) already have a SQL
> database setup.
> What really needs to be described is the specific requirements that will
> force ht://Dig to move to an SQL database backend.
> Without that specification, the choice of moving to a SQL backend is
> silly and a waste of time and energy.
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
