[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: A search service for KDE
From: Fred Schaettgen <kde.sch () ttgen ! net>
Date: 2005-04-04 11:20:22
Message-ID: loom.20050404T115527-214 () post ! gmane ! org
[Download RAW message or body]
Aaron J. Seigo <aseigo <at> kde.org> writes:
>
> On Sunday 03 April 2005 06:26, Fred Schaettgen wrote:
> > AFAIK the kfile plugins don't support this at the moment, do they?
>
> no. but there's no practical reason that they couldn't be extended to do so.
> they are rather slow though. i don't know if simple optimization is enough,
> though; it may take reworking the API completely.
The difference between the usual metadata and fulltext data is
that for the complete text you have to read the whole file usually.
The size of the returned data could also become an issue with
huge or broken files, if we don't want to introduce arbitrary
limits for the size of the fulltext data. So I thought that a
stream interface which can report progress like a kioslave could
be the better approach here.
On the other hand we could also extend the kfile interface for
KDE 3.5 with a getter for fulltext data and a size limit which is
sane enough until KDE 4 and change it to something better for KDE 4,
if it turns out to be a problem. Then plugin developers still
wouldn't have to wait for KDE 4 to get started.
> > But one part which could be more easily shared among different search tools
> > is the set of plugins to extract text from different file types.
> > The interface for these plugins should become part of kdelibs. Then we
>
> they don't even necessarily need to be part of kdelibs. depending on how
> broadly applicable they are meant to be they could have very few dependencies
> and exist as an independant library/project. really depends on how generic
> they would be.
Agreed, the plugin interface (and of course not the plugins themselves)
doesn't have to be part of kdelibs. But defining the interface in
kdelibs would keep KDE self contained without adding new dependencies.
The code behind the interface towards the application, be it kfile
metainfo or a fulltext kioslave can still be extended to use
non-KDE-plugins. But I'm more interested what the interface for the
plugin which will potentially be included in KDE will look like.
If we want to avoid opening files twice for metainfo and fulltext,
then we would have to extend the kfile metainfo plugin interface. If we
think that this doesn't matter much, we could also use simple filter
commands, so plugins could be written without KDE-dependencies by
simply reading filenames from stdin and writing (xml-encoded?) fulltext
data on stdout.
So the question has two parts:
- What should the interface towards the application look like?
fulltext kioslave or metainfo extension?
- What should the plugin interface look like?
kfile plugin extension, new c++ plugin type or filter?
> if we want something in kdelibs, we may as well just fix/extend KMFI, IMO.
If we use filters as the plugin interface, then we could easily
expose the plugins to the application with a kioslave, so every
KDE program could use it instantly without adding new build
dependencies.
* Drawbacks: not perfectly efficient if both metainfo and fulltext
is indexed
* Benefits: No new runtime dependencies for applications, no changes
to kdelibs, no build dependencies for plugins, plugins can be written
in python or whatever.
Could you live with such a solution? Any better ideas?
> >it could be helpful to factor out parts which can be shared among these
tools
>
> agreed. another part that can be shared is an indexer/updater daemon. the
> parts that are solution-specific is the actual final data prep and storage.
Hm, probably. But that's harder to agree on than the fulltext plugins.
Let's go step by step ;)
Fred
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic