Cameron, Simon and others,
Just in case this didn't come through previously.
It's good to hear that some work is being started on establishing the existing design of Geonetwork. I have started some of this myself looking into the GN Java side class/method relationships and the InterMap Javascript/XSL function relationships/calls. Basically what I've produced is a couple of (big) matrices with the same set of artifacts as column and row headings, with the cells as intersections indicating the type of connection between any two classes, methods, functions or combinations thereof.
Part of the reason for doing so lies in the fact that whilst there are diagrams available that look something like what you've attached to your one of your emails, there is no overarching document showing any real detail about the sorts of connections across the boundaries that you've identified or internally to any of the 'blocks' shown on your diagram.
BTW, in the main, the code that I've examined is not too shabby and doesn't seem to contain too many inconsistencies. However, amonsgt the Javascript there are several superfluous files that are either not used, or as in one case, only two functions are used out of what seems to be a completely unrelated application to do with online purchasing using credit cards. Other potential inconsistencies crop up when JS functions that probably should be within in the InterMap JS files appear in the XSL code. There is also a little bit of pure 'convenience' usage within the XSL stuff of JS functions within InetrMap. At this point in time, there's not too many inconsistencies. My concern is that they might grow and make the code even harder to decipher.
This takes me to commenting on the fact that the Geonetwork system (including Intermap) is largely undocumented/uncommented code. If one takes the system as is with no need to enhance/change the code, then there's no real problems (at least from the user perspective) other than reporting bugs and waiting for them to be fixed. However, if (like we are required to do at Software Improvements) one has to provide extensive changes touching on many of the different elements of geonetwork, then it is very time consuming getting to a position in order to be able to define a strategy to design and implement something that is going to both fulfill the customer requirements and at the same time be relatively independent of future changes to geonetwork.
I'm seeing exactly the same set of issues associated with a number of other opensource systems where all the knowledge, design decisions and (apparently) the requirements are represented in code and little else. - and these systems are supposed to be reusable!! All of these systems have grown to a point where the most effective path is to capture the designs and document them together with requirements, associated tests etc. Unfortunately, there's a cost, and no-one seems willing to pay despite the fact that the cost of inefficiency will continue to grow with time and ultimately threaten the very survival of the systems. It seems to me that with what I've been doing together with what the developers (Richard and Ming) have had to do, it's time for the Geonetwork software to undergo some some strategic thinking if it is to be of continued benefit to it's current and future (hopefully larger) community.
So, an appropriate, low cost, strategy at this time in the development of geonetwork would be to have a community wide investment in providing adequate commentary in the code. After that, it would be appropriate to re-engineer and document the design (already started). Then the requirements (preferably in the form of a comprehensive model) that have led to the current version together with how they relate to the design, should be followed up. Whatever is done in terms of documentary improvement has to be kept up to date with (continuing) change - in short, proper change control. Doing this would potentially grow the user/contributor base because the system would be easier and quicker to comprehend, and (at least) obviate the wastage of time inevitable when having to essentially undergo the (typically undocumented and partial) re-engineering process, repeatedly. Doing all this would also provide a better platform for the gate-keepers of geonetwork to assess impacts of change and to monitor who is contributing to what part of the system and doing so independently - again avoiding wasted time. Finally, with this work an appropriate test suite could also be developed and updated with changes. Any contributor would have to demonstrate clearly what requirements they are treating, how they affect/impact the design/code and demonstrate validity through system and acceptance which are added to the current suite. Obviously, a significant load would be taken off the gatekeepers because the responsibility of ensuring that updates are accepted is largely thrown back on to contributors.
I'll be following up with more suggestions in the hope that the community might eventually decide that at least some of what I'm suggesting is sensible and will allow greater product stability, quality and productivity for all contributors and users.
Clive.
Clive Boughton
Software Improvements
Canberra Australia
Tel: +61 (0)2 6273 2055
Mob: +61 (0)410 632 055