bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

A proposal for Summer of Code.


From: Debarshi 'Rishi' Ray
Subject: A proposal for Summer of Code.
Date: Fri, 9 Mar 2007 22:28:09 +0530

http://www.gnu.org/software/soc-projects/ideas.html

I came across some proposals regarding GNU Findutils on the above
page. All though they sound very interesting, I would like to suggest
an idea of my own. I am interested in pursuing Summer of Code this
year as a student, but before going headlong with my proposal, I am
keen to know whether this is useful or not, and would like to have
your opinion.

I find that GNU Findutils, especially the updatedb and locate
commands, do a very good job of indexing information regarding files
on the filesystems. The good thing is that they are all command line
tools, and hence the absence of any GUI-related stuff makes it
possible to use them on quite low-end machines. Similar GUI tools like
Beagle(http://beagle-project.org/Main_Page) or Tracker
(http://live.gnome.org/Tracker/WhatIsTracker
http://www.gnome.org/projects/tracker) usually require the presence of
a graphical environment which might not be present on many GNU
installations.

However the current Findutils components do not look at the meta-data
of the files on the filesystems. They only look at file names. It
would be really nice to make Findutils meta-data friendly. Tracker,
for example, does provde a command line utility, but it is not yet a
part of all standard GNOME installations, whereas Findutils is quite
an integral part of any GNU based system. Moreover the presence of
packages like GNU Libextracter
(http://www.gnu.org/software/libextractor) make it really easy to
extract the meta-data from various kinds of files using on a X-less
installation. One can keep writing back-ends for handling more and
more file types to Libextractor to broaden its support base.

To avoid adding an extra dependency on a Libextractor-like package, we
can make the meta-data support optional. If Libextractor is absent we
simply do not build the meta-data support. Maybe we can have provision
for using any one among a pool of packages which can extract meta-data
of files. So if Libextractor is absent, but Foo is installed we simply
chose Foo during the ./configure stage.

We can either modify the existing updatedb and locate tools, or write
some separate meta-data capable components for Findutils.

What do you think?

Happy hacking,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]