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

List:       kde-devel
Subject:    Re: Adding improved file search to KDE
From:       Manuel Amador <rudd-o () amautacorp ! com>
Date:       2004-06-15 18:15:57
Message-ID: 1087323356.8767.95.camel () localhost ! localdomain
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


El mar, 15-06-2004 a las 13:01, Jonathan Gardner escribió:
> On Tuesday 15 June 2004 02:43 am, Cyrille Berger wrote:
> > > The only metadata we should store are the file's name, title (if
> > > applicable), permissions, ownership, and last access "score". Also,
> > > file type and category will be recorded.
> >
> > why not go further and storing the medata informations of a mp3 or a divx
> > ?
> >
> 
> We'd have to have the library functions to be able to extract the metadata 
> from those files. Don't Open Office documents have meta data as well?

yes, which is why metadata extraction plugins are candidates for third
party supplied applications, which app creators would distribute with
their apps.

> 
> > > Any thoughts?
> >
> > It look like WinFS, I hope it won't be as ressource consuming as WinFS
> > will be.

it will consume resources, probably a lot, but if the user interface
exploits this kind of architecture, you'll see the resource investment
paid off.

> >
> 
> Yes, it will consume resources. The question is when and how much. I see it 
> as running slowly in the background, careful never to consume resources 
> when resources are in demand. But when the system is idle, it will work 
> faster. It'd have to be careful not to force files that should be in the 
> cache to swap.
> 
> > And one question, what will happen when someone want to save a file ?
> 
> If they save through the KDE API, then we could send a message to the 
> indexing process. The indexing process will pick that up and put that file 
> next in the queue of files to index.
> 
> If the user won't mind a second of additional delay, we can probably just 
> index the file on the spot as it is already in memory.
it's nearly instantaneous.


oh, this kind of thing should be platform-independent in the sense that
it has to be as portable as possible, use as few libs as possible, and
even has a command line interface, so ISVs can count on it being
installed on as many platforms as possible.

I was thinking maybe I should prototype something in python, which sort
of goes against what I just said, but you'd get a secure thing that
would work fine at least as a prototype.


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

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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