[GRASS5] Porting list

[Hamish]

> > 'Missing' and missing modules cannot stop 5.8/6.0 release.
> > For me, it is important to get a short list of modules (functions)
> > realy missing in 5.7, with an explanation why it should be ported,
> > rather than a long comparison of bin directories.
> 
> I agree completely. Just because something was in GRASS historically,
> it no reason--by itself--that it should be ported to 5.7.

I agree too. One of the nice points about 5.7 is that is doesn't include
lots of old bloat. We should only spend time to port things that are
still useful: just because we can doesn't mean we should. Same goes for
adding every available command to the Tcl menus IMO.


[...]
> Another example is the discussion about the appropriateness of adding
> kriegging and geostatistics or leaving it to another package.]

If we can fix the bugs in s.surf.krig without too much trouble, sure why
not? We can always add a link the the help page pointing to the R
solution if the user wants something more serious. But because (probably
better) alternatives already exist it shouldn't be a high priority.

 
> Overall, I'd personally like to see:
> 1) more generic tools and less very specific ones (e.g., a generic
> anisotropic spreading module rather than just one specifically for
> wildfires), and
>
> 2) an easier way for users to develop and add in specific tools to
> GRASS-along the lines of a 'plugin' or an ArcView extension. (Except
> for scripting, this currently requires programming in C and users
> compiling from source to add a particular new function.) This way,
> users could more easily tailor GRASS to their particular needs while
> development could focus on powerful, generic tools that could be
> adapted to many specific uses.

(1) provides (2) via shell scripting or with "simple" languages like
python or perl. If we provide generic low level commands (eg mapcalc),
then C isn't needed to get things done (it's just more efficient).
I think we already do this pretty well.



Hamish