From kde-devel Mon Apr 04 11:20:22 2005 From: Fred Schaettgen Date: Mon, 04 Apr 2005 11:20:22 +0000 To: kde-devel Subject: Re: A search service for KDE Message-Id: X-MARC-Message: https://marc.info/?l=kde-devel&m=111261396315379 Aaron J. Seigo 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 <<