Re: Followup: opinions on Search services

El mié, 27-04-2005 a las 11:50 +0100, Jamie McCracken escribió:
> Manuel Amador wrote:

> >
> The optimal

c''mon you got to be kidding me!

>  solution IMO is to have a 100% C daemon that uses libgda for 
> DB access (IE provides abstraction to sqlite, mysql, firebird, postgres 
> etc).

I'll never, ever, EVER do it in C.  I've done my share of C and I've had

>  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

Not true.  Python does ref counting along with garbage collection.

>  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).

Red Hat?  launch system-config-services.

>  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.

That is true.  We should be cautious.

> 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.

Search services has already included a python-mysql module which embeds
a MySQL database, to provide for zero configuration startup.

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

Yeah, that''s true but I did not know D-BUS at the moment =(

> 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.

Oh, but we do.  A common text index does not work at all for very large
strings (such as document contents).

> 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!).
> jamie.
Manuel Amador <rudd-o amautacorp com>

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