On 08-01-2005 20:58, "Stefano Mazzocchi" <[EMAIL PROTECTED]> 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! Cheers, - Leo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
