[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]