Re: Followup: opinions on Search services

Manuel Amador wrote:

3) It really needs to be a freedesktop solution written in C cause it looks likely that KDE will produce their own solution so adding to a lot of needless wheel reinvention.

The KDE solution has a different focus.  I've been talking to the klink
people regularly, and they have placed their faith in the value of
relationships instead of the value of data.  I hope that turns out great
as well =).

The optimal solution IMO is to have a 100% C daemon that uses libgda for DB access (IE provides abstraction to sqlite, mysql, firebird, postgres etc). KDE is more interested in conceptual linking of data and thats really easy to do with an sql DB cause the data is highly relational in nature (and its one area that flat file databases like lucerne will *probably* struggle - I've not used lucerne so thats a guess but I haven't read anywhere that lucerne is a fully relational database).

The big problem with daemons written in garbage collected languages is resource usage and the inability of ordinary users to turn off an invisible background service (its not a big deal if a gui app is eating too much memory cause the user can close it down). Im not saying dont use them for this but we need to be cautious about their impact - they are a *potential* threat to system stability particularly on systems with lower amounts of free RAM.

Supporting embeddable DBs (sqlite, firebird) is very important as it means they will just work out of the box with no configuration. KDE's Tenor plans on using Postgres which looks foolish as setting up postgres is a technical task beyond most users and so looks certain to fail.

Its desirable to make use of things like Dbus rather than plain sockets as it makes interfacing and integrating stuff a lot easier.

THe text searching can be done with sql "like" or optionally with "glob". We dont need google style ranking or show me similiar pages etc so the sql DB route looks very feasible.

We also want to avoid significant dependencies (like a big RDBMS, additional runtimes, libraries and frameworks etc) so that adoption is much easier.

I believe a freedesktop implementation is possible and desirable as I cant believe anyone will be happy running two separate indexers if they use a mixed kde/gnome desktop. If anyone is interested in doing this please let me know as Im considering implementing it myself at some point (when I have the time!).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]