Cameron, Simon and others,
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.
Cameron Shorter wrote:
We had a very productive face to face meeting last week to discuss the
design of an enhanced Geonetwork metadata record collection interface
last week.
Present:
Simon Pigot (CSIRO and Geonetwork developer),
Evert Bleys (BRS, representing the customer, and expert on ANZLIC
profile),
Roald de Wit (LISAsoft, developer)
Simon Green (LISAsoft, developer)
Cameron Shorter (LISAsoft, project manager/tech consultant)
Simon and Roald have started writing up the design, diagram is attached,
and we would like to determine a good place to put the rest of the
design. We can set up a wiki on the LISAsoft website, but I suspect it
would be better to use a Geonetwork wiki? What do you think?
Next, could we please get accounts for Roald, Simon and myself to the
geonetwork svn sandbox.
My preferred username is camerons.
Roald, Simon, could you please suggest your username.
--
Cameron Shorter
Geospatial Systems Architect
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254
Think Globally, Fix Locally
Commercial Support for Geospatial Open Source Solutions
http://www.lisasoft.com/LISAsoft/SupportedProducts.html
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
--
View this message in context: http://www.nabble.com/Geonetwork-UI-Design-tp17466962p17481018.html
Sent from the geonetwork-devel mailing list archive at Nabble.com.
