>
> Personally I worry about this. I think that while many people want to see
> a SQL backend, there shouldn't be a dependency on installing SQL. The
> Berkeley DB is fairly lightweight, installed on many systems already, and
> fairly robust.
>
I agree with you. This is so problematic that I can't imagine a solution
at present. A high factor of success of htdig is that it's simple to install
and does not require anything but a C++ compiler. Depending on a SQL database
will break that.
> Yes, I agree that you don't want to emulate Berkely DB behavior with a SQL
> database. However, we have much of the code for advanced features like
> ANDs and ORs and LIKE in the code already. Moving to SQL would simplify
> it, but should we just throw out this code?
I don't think we should throw away any code unless we have a good reason
to. We should probably dig the internet to find projects that have a problem
similar to this. I don't know any, do you ?
> (My answer would be "no, we should see what features from SQL we would
> *need* and think about how hard those would be for Berkeley DB with what
> we have now.")
My answer would be : if we want to keep Berkeley DB in the loop, we don't
want SQL database at all. What would be the benefit ? If the code is
designed so that it remains Berkeley DB compatible, why would you want to
use an SQL database ? Berkeley DB is scalable, robust, fast. I we don't
do use anything in the code that Berkeley DB is unable to do, we loose all
the benefit of using an SQL database. Introducing an SQL database will
require quite a lot of work and bring no benefit.
--
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.
