Torsten Neuer wrote:
all point that where snipped away are to beconsidered valid and being
taken into account.
> > 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.
>
> Ht://Dig has (afaik) no limitations for its use.
> MySQL has a restricted licence.
>
> I can see some disadvantages for the use of Ht://Dig in focussing on a
> specific SQL server - especially one that has a restricted licencing
> policy.
>
> You may also want to keep an eye out for other platforms and therefore
> need to support SQL engines on those, too.
I wouldn't concieve of writting a SQL DB backend and not at least make
it easy for people to wrap other DB API's with it.
> > 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.
>
> Such an abstraction layer should be very generic and provide interfaces
> to
> multiple SQL engines as well. Maybe there is a way to borrow from
> PHP/Zend
> code?
shrug, no actual time to work on it now, I'm afraid, so I don't know,
but at the very least I would want to make it easy to change by
recompiling. note that I said at the very least. we shall see
> And these are not the only changes neccessary to move to a SQL backend,
> but
> you also have to modify the behaviour of the Ht://Dig configuration,
> which
> now is defining directories and files but should be naming SQL databases
> and
> tables in case an SQL backend is configured.
nod, I understand that this will be a very large undertaking(well small
compared to writing a search engine, but...) which is why I want to
abstract as much as possible, upto and perhaps including the Berkeley
stuff, as little as possible should change in terms of actual use of the
product. I'm actually thinking that the current setup might not be as
hard to abstract as people are thinking. there seems to be a DB class
that returns a reference to DB2_DB, that might be good enough that with
minor changes, we won't have to worry
> > 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.
>
> It might make Ht://Dig better suitable for large scale applications than
> it is now. As Marc pointed out, an SQL backend is able to increase the
> performance of Ht://Dig both with indexing and with searching the index.
> It might also help adding concurrent indexing/searching (i.e. searching
> a database that is constantly updated), which is sure good to have on a
> large search site. For smaller sites however, it would just be an
> overkill.
correct, and I'm doing work with the LinuxKB site, which(with luck) will
have a ton of info in it, and constintly need to be updated. It occured
to me when I saw that want for a SQL backend that this might be the key
that they will need.
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
