Re: A proposal for Summer of Code.

[James Youngman]

On 3/13/07, Debarshi 'Rishi' Ray <address@hidden> wrote:
> Here is a draft of my proposal:
> http://glug-nith.org/~rishi/download/soc/soc-proposal-findutils
>
> It would be nice to know your suggestions and comments on it.

It's an interesting proposal, and well-written.

The first part of the project is very interesting.  An incrementally
updating updatedb database is a very interesting idea.

The second part of the proposal is also interesting from the point of
view of functionality, but it raises difficult issues of architecture
and functionality.  Findutils is part of the base install, and having
it begin to depend on libraries like libextractor would produce
tremendous bloat in the package.  There is also the issue that find
needs to be able to work perfectly well when the system is booted into
single-user mode (and there is something wrong with it).

So I would suggest that you modify the second part of your proposal.
I suppose it would be possible to have some kind of 'plugin'
architecture for findutils.  Plugins could add new tests to find and
locate, for example.   By using a plugin architecture, we have a
situation where (for example) a libextractor plugin for findutils
depends on libextractor and on findutils, but findutils does not
itself depend on libextractor.   I think that this is a more suitable
way of  supporting 'application layer' functionality in a tool that is
also designed for system administration.

Things that a plugin architecture would need to think about would be:
* How to manage interface versioning
* How to install header files which define the inerface itself
* How much of the current findutils headers need to me moved or
factored out (e.g. probably parts of find/defs.h).
 * How to load the plugin in such a way that we minimise
system-dependent coding in the C code and in the Automake Makefile.am
files
 * How to adapt the current data structures in order to allow new
find predicates to be registered.

I'm sure there are other issues that would need consideration.

James.


James.