[GRASS5] GRASS extension manager proposal

[Benjamin Ducke]

Hi everyone,

as I am making good progress porting my belief modelling tools
to 5.7, I realized they would make an excellent example for
a new 5.7 extension manager.
My tools consist of quite a few separate modules plus helper libs
and instead of merging all of that into the already quite full
"raster", "vector" etc. dirs, I would like to package them
as an external extension which everyone interested could download,
compile and install from inside their GRASS installations,
without having to merge the code into the source tree first.
I would then try and code a little user frontend program 'g.install' which
would take care of all the installation issues.

Michael has told me that some of you have already spent some
thought on it so could you fill me in on how far you got?

My ideas are:

For each extension:
- put all source code and binaries for selected systems into
  a tarball
- also add some standardised ASCII description files to the
  tarball:
	- version information
	- binary and dependencies information
	- source URL and author info
	- Tcl/Tk menu code for the GIS manager

For GRASS 5.7:
- the g.install module could be used to
	list, install, update and remove extension
        binaries and documentation

- installation could be system-wide into any GRASS bin tree location
  the user has write access to or user-only into a directory
  into a dir under the user's current location or mapset.

- a new menu entry 'Extensions' in the GIS manager where extensions
  can register their modules in a submenu and hooks for g.install
  to query, update or remove these extensions are provided
	

For a future perspective, I think the R approach of putting all
functionality into packages would work quite well.
R includes the most important packages in the main distro and
has a simple install tool for users to add whatever they need.
GRASS already has very many modules and browsing the documentation
list to find the right module has always been
a bit of a challenge, since their is nothing except the program
name to hint at a module's purpose.
So, I would think it a useful thing to group modules by functionality
such as 'base', 'spatial statistics', 'imagery',
which would also be reflected in the source tree organisation and
the HTML documentation structure.

What do you think?

Cheers,

Benjamin