[GRASS-dev] add-on structure

[Martin Wegmann]

Dear GRASS-dev folks, 

to keep the 'add-on' idea in the mind of everybody and discuss the potential 
structure/limitations/pit-falls Markus and I summed up a few ideas/suggestions 
to provide a starting point for in-depth discussions and a initialisation of 
an add-on structure:

Just for clarification how I use certain words:

- main: path to GRASS-main code (restricted to GRASS-main developers)
- add-on: path to additional function (moderated "public" develop.)
- commands: well, single commands ...
- packages: bunch of commands dealing with a certain issues


software constraints:

- migration to svn is necessary to have restricted/selective
  access for main and add-on


add-on manager (person):

- an add-on manager who checks incoming commands/packages for their quality 
  (code, help, man-pages)
- a status for fresh commands would be good (fresh commands vs. "officially" 
  accepted commands) -> how does R deal with it? Automated builds could
  be done on grass.itc.it along with a status page


GEM

- packages installed via UI or CI via WWW or local
- packages updated via UI or CI
- packages afterwards permanently loaded in certain location/mapset and 
  not in others
- package removal from location/mapset


add-on structure:

(I orientate myself on the R structure, because I am familiar with it and 
like it, if anybody else has different ideas, please feel free to discuss 
it)

- setup of different packages for different topics (classif., hydro., 
landscape ecol., spatial model. etc. see below)

- every command is assigned to a package, even the "old" one, just to keep the 
structure consistent (?) - assigned to package "base"?

- r.*, v.*, i.* commands might be together in one package and installed 
simultaneously - no splitting between r./v./i. commands in separate packages

- after loading in UI: 
raster/package_name->command
vector/package_name->command
--> no merge inside "base" commands but in separate dir in UI

- broad package topics for starting point; in the future further splitting 
might be necessary to keep it simple:

-- data handling
-- Geo-Statistics
-- GIS tasks
-- image classification
-- hydrology
-- spatial modelling
-- landscape ecology
-- fire modelling
-- bathymetry
-- data enhancement
-- ...

I would suggest to list all commands in the man pages with their package 
affiliation in brackets and not to list them only if package is loaded or in 
separate directory.
An idea could be to assign 5 keywords to each command/man page from a
list of key words (semi-automate that?)

any further ideas, doubts etc. concerning an add-on system?

regards, Martin





-- 
Martin Wegmann

DLR - German Aerospace Center
German Remote Sensing Data Center
@
Dept.of Geography
Remote Sensing and Biodiversity Unit
&&
Dept. of Animal Ecology and Tropical Biology
University of Wuerzburg
Am Hubland
97074 Würzburg

phone: +49-(0)931 - 888 4797
mobile: +49-(0)175 2091725
fax:   +49-(0)931 - 888 4961
http://www.biota-africa.org
http://www.biogis.de