--===============1795384480==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-Owl6Fx34E10s119CXMsS"


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

El mi=C3=A9, 09-06-2004 a las 16:18, Dik Takken escribi=C3=B3:
> > Indexing may be useful for one plugin but useless to another. Metadata
> > extracting will probably be meaningless for most plugins.
>=20
> I disagree on this, though.  For most plugins, metadata extraction would
> be great.
>=20
> Note when I say plugin I mean a specialized piece of software that
> extracts data/metadata from a file, then feeds it onto a searchable
> index.  NOT a search UI plugin.
>=20
> Throughout this discussion, a search plugin is understood to be a piece o=
f=20
> software that searches for anything that you could search for. A plugin=20
> to search for files is just one of many possibilities. And yes, metadata=20
> extracting is useful for files. But what is the meaning of the term=20
> 'metadata' for a Amazon.com DVD search plugin?

We've been talking different kinds of plugins all along.  I was talking
more of a "content/metadata indexer plugin".

Let me paraphrase: You're advocating a search interface which would use
plug-ins to collect search results from different sources and collate
them for the user.

I'm advocating a metadata/full-text-search/indexing system, with a
search interface which would contact a single search service for results
and notifications, while the search service would use indexer plug-ins
to collect metadata/data from different file types.

As long as we're on this, it's clear you could write a search plug-in
which would contact the indexing service on the local machine (or who
knows perhaps the LAN), which would be fed data/metadata by indexer
plug-ins.

It's heavy.

>=20
> What you are talking about is the internal working of the file search=20
> plugin.

Not really, but I know now why we digress, and it's okay that we've been
digressing, because we've different goals.  You want to enable KDE to
search for data in many sources, while I want to enable KDE to search
for data in the local machine / network.  As you can see, both goals are
good.

>  That's not primarily what this discussion is about. This=20
> discussion is about the general search framework of KDE and how to extend=
=20
> it to a much more generic and powerful tool.
>=20
>=20
>=20
>    -----------------------------------------------------------------
> _______________________________________________
> 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

--=-Owl6Fx34E10s119CXMsS
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)

iD8DBQBAyL2bWyznNMEDPK0RArtKAJ0YyWvzOY0iCqh7Y/qKZjcWLogodACfQSv9
OtI6ekIDRLL+piGAt9H9gJA=
=xGG9
-----END PGP SIGNATURE-----

--=-Owl6Fx34E10s119CXMsS--


--===============1795384480==
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

--===============1795384480==--