[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Easier Searching in KDE
From:       Manuel Amador <rudd-o () amautacorp ! com>
Date:       2004-06-10 20:25:13
Message-ID: 1086897563.3882.10.camel () localhost ! localdomain
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


El mié, 09-06-2004 a las 16:18, Dik Takken escribió:
> > Indexing may be useful for one plugin but useless to another. Metadata
> > extracting will probably be meaningless for most plugins.
> 
> I disagree on this, though.  For most plugins, metadata extraction would
> be great.
> 
> 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.
> 
> Throughout this discussion, a search plugin is understood to be a piece of 
> software that searches for anything that you could search for. A plugin 
> to search for files is just one of many possibilities. And yes, metadata 
> extracting is useful for files. But what is the meaning of the term 
> '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.

> 
> What you are talking about is the internal working of the file search 
> 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 
> discussion is about the general search framework of KDE and how to extend 
> it to a much more generic and powerful tool.
> 
> 
> 
>    -----------------------------------------------------------------
> _______________________________________________
> kde-usability mailing list
> kde-usability@kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
-- 
	Manuel Amador
	Jefe de I+D                         +593 (9) 847-7372
	Amauta                     http://www.amautacorp.com/
	GNU Privacy Guard key ID: 0xC1033CAD at keyserver.net

["signature.asc" (application/pgp-signature)]

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


[prev in list] [next in list] [prev in thread] [next in thread]