gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: The Gump3 branch
Date Sun, 09 Jan 2005 14:49:47 GMT
On 08-01-2005 20:58, "Stefano Mazzocchi" <> wrote:
<big snip of lots of stuff/>
>> I see you have a Maven parser, but could/should
>> that be a plug-in?
> This is *EXACTLY* the kind of question we should *NOT* be answering. It
> does *NOT* matter if it's a plugin or not, as long as it does the job.
> Early refactoring is the root of all evil, even worse than early
> optimization.

Well, I think I disagree that's the case here. What I did was a pretty
"late" refactoring of gump2. What Adam is basically asking "is that
refactoring now done?" and the answer is probably "not completely". It makes
sense to figure out at this point if there's some big architectural flaws to
catch now and change.

Please do be critical and ask those questions! The answer could just be
"no", but that just makes us all more confident that we're on the right
path...I really don't mind takin a week or two to be sure of that.

Thinking more about that Q re the to-be-built maven parser...basically you
could have 0..n "Normalizers" that chain up to all change small bits of the
xml model. Sounds like a pipeline of cocoon transformers :-D. Fortunately
that change is kind-of isolated since you could just refactor the current
Normalizer internally to consist of multiple smaller components.

An alternative might be replacing the normalizer with a wrapper around an
XSLT script to handle the transformation. Or ... Or ... :-D

The same could probably be said of all the other xml handling bits. For
example the Objectifier could probably be split into one small class for
each different kind of tag that needs to be turned into a python object.

I suggest we don't worry about that for now (no need to build another cocoon
in python! :-D) but keep in mind that its possible.

> A lot of what Leo has done is to reduce the (bloated, percieved or real
> I don't know) complexity of Gump2, if you start moving stuff over from
> Gump2 to Gump3 before *others* had a look at the new (and much simpler)
> code, we go back to a one man show and the entire effort is useless.

If that would really be the case then the refactoring effort would have
failed. I would hope that adding an RDF generator plugin would be adding a
single sourcefile somewhere where it is easily ignored by someone just
learning the system internals.

Nevertheless, I do agree with:
> so, please, let's work as a team in identifying what needs to be done,
> outline the priorities and then allowing code to get in.
> priority #1: avoid one man shows.
> priority #2: keep it simple, stupid (to help people understanding the
> code, then helping on #1)
> priority #3: achieve separation of build from presentation
> priority #4: implement a very usable command line interface
> everything else (including sending email!) will come later.

Concretely, doing a grep for "TODO" should show lots of places where I think
the existing code needs work :-D
> Avalon had the notion of a component lifecycle and this is what Leo is
> doing here.

Ssssh! :-D

> no, and we don't need one: you need mysql and if you don't have it Gump3
> won't run. That's as simple as that.

+1 to that. Some decisions about that which are implicit in the new CLI as
I've been building it:

* python 2.3 with all its libs
* unix environment (cygwin will do, probably)
* mysql
* bunch of python libraries we choose to use (like MySQLdb)
* bash, java, ...

The bash script simply checks for all this and complains if something is not
there. Grepping that script for the word "check" hopefully results in a full
list of required software :-D

Next week is scheduled to be rather busy so it might take a while before I
have time to reply!


- Leo

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message