[GRASS-dev] GRASS-TNG

[tlaronde at polynum.com]

On Wed, Feb 21, 2007 at 10:27:48PM +0100, Radek Barto? wrote:
> 
> Correct me if I'm wrong since I don't know KerGIS as well as you, but compared 
> to GRASS-TNG KerGIS is:
> 
> It is not object oriented nor component oriented.

I'm more than 18 years old, so commercial hype doesn't impress me the
least. KerGIS is object oriented when that does make sense (see
libcorr). But it does not use C++ for reasons already stated by Frank W.


It is component oriented: what do you think libraries are? What do you
think the reorganization of the whole source in an orthogonal base is?

> It is independend in mean that its program itself.

I simply don't understand what you are trying to say.

Yes, it's a standalone package, depending on nothing except a POSIX
environment and, for display, X11.

It's one of its strengths.

> It is not a proove of concept or some kind of research how to improve GRASS 
> itself.

??? How do you define "research"? Negatively: not actual code or result?

It's an improvement over the actual code base of GPL GRASS. It is a
"research" project because it leads to many open questions.

If "research" means---this is unfortunately the same in France---some
vague pretext to lead to nothing actual so that nobody can judge the
result, no: KerGIS is not research.  It's useful and used.

If you really want a research project, there are numerous ones that are
really open in the field, with no correct or practical solution, take
all the graph problems for example.

If you want to give useful results, data, for example with threading,
there is a lot to do (just to have numbers about what are the great
gains, and what are a lot of headache for little gain):

1) With multiprocessor, the simplest with actual kernels is distributing
distinct processes on distinct CPUs on multi-CPU systems. No thread
here, but using tiling will allow to launch processes in parallel on
each tile. What is "tilable", what is the gain ?

2) When threading is enable, take a data treatment (not a GUI) and
implement threads. What are the gains on N:1, 1:1, N:M with SA, without
SA etc (since threads are still an open problem and thread
implementations are still young this is an open problem; and not an easy
one; and not a priority for GRASS: cleaning and orthogonalizing will
allow someday to benefit, for some parts, of threading; not now);

etc.


At the moment I do not understand what you are aiming for except that
logically:

1) if your work is related to GRASS, you can not think about the
organization of the upper layer without knowing first the lower ones
(for now your documentation is just paraphrasing programming with
components; this is all well-known, generic, and has nothing to do with
the pecularities of GRASS). The problem is not how the upper layers
should be organized. The problem is to reorganize the lower layers so
that the upper layers are simpler.


2) if you can design your project without having to refer to or know 
GRASS, I don't understand why GRASS even comes in the figure.

Please note that I haven't used the term GRASS in the name of my project
to avoid confusion with GPL GRASS, while it is a fork of CERL GRASS so
it could have had some legitimity.

Even if it's none of my business, the use of GRASS (historically, now,
associated with GPL GRASS) and the GRASS logo, is holdup'ing a filiation
that is not legitimate.

Secondly, calling this: GRASS-TNG (I suspect: The New Generation) and
having as a goal not to do anything real, but explaining to others how
they should work is something that I would be unlikely to appreciate
(the tone of my mail should make this clear).

I have been rude with GPL GRASS developers from time to time, but at
least I have never said that I will only "think" and come back with
bright ideas: I said I will try another way. And I have done (still
following GPL GRASS development because I have not the monopoly of good
ideas, and because I do my share of mistakes; but because I _work_).

Just prove me that I'm wrong and that something useful can come out of
this buzz.
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C