Re: Nautilus/Medusa search index enhancements

[Curtis Hovey <sinzui cox net>]

On Mon, 2003-02-17 at 14:35, Manuel Amador (Rudd-O) wrote:

> The full path name to a file should no longer be stored. Now Medusa should 
> store the volume's unique ID (GUID, whatever), and the volume name, along with 
> the base path (say a file is /usr/lib/gkrellm/plugins/ and /usr is a 
> filesystem, the base path here would be /lib/gkrellm/plugins).

That's a good idea.  I've noted the problem while tinkering with medusa.

> Medusa should be signaled by autorun whenever a drive is inserted, or 
> by 'dynamic' where a volume is hotplugged - the whole idea being that Medusa 
> should detect mounts and act accordingly
> Medusa should start indexing files if it's a new volume or begin monitoring 
> files there for changes. 

We need to reconcile that medusa is now a user application.  Each user
would need their own preferences.

> Network scenarios
> Great huh? Now imagine this gets extended to support NFS networks. Medusa could 
> be accessible via the network (a medusa search service in my local machine 
> could, instead of indexing network mounts, delegate the search to the medusa 
> search service at the machine where the network mount is exported), much the 
> way SGI FAM does.
> 
> Medusa should also respect the /etc/exports conventions.
> 

I believe it has from the start.  You can configure which file systems
to not index.  What it doesn't support it multiple roots for an index,
requiring users to create many indexes.

> (*) FAM delegates file monitoring to remote FAMs. When FAM cannot connect to a 
> remote NFS FAM server, it falls back to standard dnotify. This behavior can be 
> mimicked in Medusa-searchd. To prevent failed file accesses, removable media 
> search results wouldn't be returned to the client search service.

FAM will be useful when preforming incremental indexes.

> Medusa-searchd in the NFS server should accept remote connections if the NFS 
> server is up

Medusa-searchd doesn't exist in medusa-2.0.

> I have the feeling that a couple of changes in Medusa would render its 
> usability much greater than the current prospect. I bet if this gets worked 
> upon, even the KDE people would get around to using it. Remember how ugly and 
> slow the search box in KDE is. And another thing: it's slower than Windows' 
> file search tool. KDE already takes advantage of SGI FAM. Medusa could be the 
> search service everyone expected.

While that would be great, KDE is prejudiced towards C++.

At this time, getting Medusa to work with Nautilus is the first
priority--The user level indexes do not work with nautilus, which still
looks for the old medusa-searchd.

-- 
__C U R T I S  C.  H O V E Y____________________
sinzui cox net
Guilty of stealing everything I am.