--===============1229438262==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-FH6/4EBHq72bt6MsrPZL"


--=-FH6/4EBHq72bt6MsrPZL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El mi=C3=A9, 09-06-2004 a las 16:34, Dik Takken escribi=C3=B3:
> > I have done some calculations with some code, and, assuming you have a
> > file indexing daemon which uses a notification system and extracts
> > metadata (and a small portion of data, say, for a full text indexing
> > database), you'd be looking at one or two seconds of indexing per file,
> > at a 20 niceness level.
>=20
> > That ain't slow.  Coupled with a register/notification
> > (observer/observable pattern for queries) system for a hypothetical
> > search daemon, you could add a word "Casaperrogato" to one of your
> > OpenOffice documents, and see it appear in a search window in approx. 1=
0
> > seconds.
> >=20
> > That's much more immediate than Windows search, and it is possible.
>=20
> Indexing and caching can only be done on a per-plugin basis, because=20
> Google won't send you notifications if anything changed for example. So,=20
> for now, caching and indexing is an implementation 'detail' of file=20
> searching plugins.

Exactly.  Perhaps at some point the index system can be extended to
index visited documents on the network or the Internet (hey, I would
like to find an article I was reading on "the culture of poverty" and I
cannot find it).  But let's keep it simple initially.

>=20
> In my opinion, file indexing and caching does not really belong in a=20
> Desktop Environment. We should either use existing DE independent systems=
,=20
> or develop one of our own that can be used by KDE search plugins.

That is also true.  Any indexing/query/search system has to be,
definitely, a DE-independent endeavor, so it be adopted by as many
projects as possible, and not starve resources used in developing the
DE.

>  I'm=20
> afraid this is a bit out of the scope of the KDE project. We develop a=20
> Desktop Environment, not a data mining solution.

That's also 100% true.  But a FLOSS data mining solution, when
pervasively integrated in KDE, would benefit KDE users enormously.

>=20
> Cheers!
>=20
> Dik
> _______________________________________________
> kde-usability mailing list
> kde-usability@kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
--=20
	Manuel Amador
	Jefe de I+D                         +593 (9) 847-7372
	Amauta                     http://www.amautacorp.com/
	GNU Privacy Guard key ID: 0xC1033CAD at keyserver.net

--=-FH6/4EBHq72bt6MsrPZL
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQBAyLw2WyznNMEDPK0RAsI0AJ9xA8iHxNqAuab+59fH3YeTxJ/xlwCfQoe4
Z845UL1Bc67YT+cebOLPTzs=
=mV/k
-----END PGP SIGNATURE-----

--=-FH6/4EBHq72bt6MsrPZL--


--===============1229438262==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

--===============1229438262==--