[GRASS5] Leaving

[Thierry Laronde]

On Thu, Nov 27, 2003 at 07:37:46PM +0100, Radim Blazek wrote:
> 
> I'am currently looking for a way how to make available my work I have done
> on GRASS vectors, under some lincense, allowing to build proprietary
> applications for GRASS. BSD with advertisement realy seems to be GPL incompatible
> and problematic. The only reasonable license, I know about, is MIT/X.
> I am not opposed to some restrictions like an obligation to publish
> modified versions, but LGPL has too many unnecessary restrictions.
> 
> Do you intend to keep format compatibility with the current and future GRASS 5.0/5.7
> versions, i.e. follow changes done by this team?

No decision taken at this moment. It could theorically be as simple as
an import module or, more involved, a compat library. But I will look at
this after. My "program" is the following (this answers some of your
questions):

1) Start from 4.1.5 (done)

2) Initial cleaning: remove all duplicates, back-ups, SAVE, support for
anything else than ps (paint), removing the main of the contributions
(userland stuff, licencing problems, non usefull stuff, etc...)
-> done

3) Fix the code (C99 and POSIX) and document the problems found
(function overheads (function just calling another function), automatic
variables not initialized (fixed but tagged)) 

[I have made only one "major" change: G_malloc and family have been 
suppressed since they were duplicating malloc, calloc and realloc 
and since the modules where G_allocating and allocating mixing 
memory allocations from to separate tools which is a main source 
of problem]

-> work in progress

4) Fix xgrass which doesn't compile due to various problems one (big)
being that the Motif version used is not the current one and that
changes have been made. But I have now the doc (O'Reilly has released
online the manuals).

===> First step: a GRASS, slimmed down, and compiling on any POSIX +X
+Motif compliant system with (gcc) -Wall and -Werror

5) Redefine the directory tree and the build system (BSD sources like)
extracting clearly what is architecture dependant and so on

===> Second step: this very same GRASS compiles and installs cleanly
from the new tree scheme.

TAG: first public release of (development name) YAG (Yet Another Grass
based GIS) under ??? licence.

And then begin to improve GRASS (DB management first priority to have a
usefull GIS). Then vector changes and so on.

The guidelines for me are:

0) Primitives not policies: YAG must provide a reliable framework for
custom application. It doesn't focus on the user level (only a small
well designed set of userland tools, no particular application), it does
focus on the system level;

1) Portability on the architecture level

2) Portability on the code level: C99 and POSIX

3) Portability of the results: use of a well documented text format for
importations and exportations for graphic and attributes (a TEXT format
for DB too)

4) Accuracy: the results shall be correct

5) Efficiency: the correct results shall be obtained with the minimum of
code, time and maintenance -> well documented code, primitives and not
policies, an orthogonal base of graphic primitives; a line debugger
allowing to inspect files and elements and allowing too scripting (for
v.digit/xdigit for example [this should allow too "undo" functions,
scripting of a user session, customization].

Note: the focus on _maintainance_ doesn't mean that the correct code
will be the smallest set of lines; it will be the smallest correct,
efficient and undestandable piece of code...

6) Scalability: YAG must be able to run on clusters
	-> All non strictly interactive tools MUST run in batch mode 
	-> Client/server architecture
	-> Multithreading (not a priority, but must be thought about)

-- 
Thierry Laronde (Alceste) <tlaronde at polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C