Jeroen Ticheler wrote:
Hi all,
16-22 June we'll meet with quite some of the GeoNetwork developers in Bolsena. I wanted to start making an agenda for that week and also see what can be done ahead to make the meeting more efficient and give others that are not in Bolsena a chance to provide their inputs early on.
We have a range of projects lined up around the world that plan developing functionality and we have to make sure these are aligned as much as possible or otherwise have a clear strategy on what, where and when functionality comes together.
At present I see two major releases we have to plan for, being version 2.3 and version 3.0. Version 2.3 could be released by 25 September (before FOSS4G2008 starting 29 Sep in Cape Town), version 3.0 by March 2009. We may discuss a version 2.4 release if 3.0 is to risky for some or there are functions that can't be finished before 2.3 and can't be ported into 3.0 in time.
I would like v2.3 to be finished before FOSS4G 2008
Rough plans for the versions (with surely many things missing and I'm also suggesting some directions, please add if I didn't add yours):
v2.3
- CSW 2.0.2 ISO
- W*S harvesting
- GeoServer integration with direct deployment of W*S services on upload of shapefiles and geotiffs
- Improved metadata editor (possibly in two flavors)
- First cut GUI plugin support
v3.0
- ebRIM CSW ISO support
- Application Profile plugin support
- upgraded web map client (discussion is needed here, using Open Layers in combination with EXTjs may be the logical way to go. Also with MapFish and with GeoServer GUI choices in mind).
- Search interface (probably rewritten from scratch) to be more modular, removing a.o. tables, switching JavaScript API to EXTjs and GUI themes as module support.
For the agenda I will put a table on the developer WIKI that we can fill in further.
Looking forward to responses & ideas!
Ciao,
Jeroen
Thoughts and ideas, some of which come from discussions I've had with people who are interested in and contributing to GN in the Australian context (and which they will hopefully expand on/add to if they feel necessary!):
Firstly, some new features we would like to be involved in adding:
v2.3/v2.4:
- Profile handling and national profiles as installer packs
- Re-use mechanisms: beginning with completing the subtemplates implementation, XLinks between elements in records local to GN and hierarchies (relations, not sure who was working on this in 2.2?) - supported by the harvest manager to proxy content from other sites/directories/catalogues
- Features from BlueNet MEST: temporal search using temporal extent (not on last modified date), improved XSD validation messages and links to editor (still under development), servlet filter for gzip'ing content, SAXON9 for progressive XSLT2 switch, default GUI: simple tab driven main page interface with modal dialogues to avoid page changes/back button inconsistencies and the editor in a separate window, Ajax techniques in editor (also still under development)
Research which we're hoping to contribute to for version 3.0 but are not going to commit to on that timeline just yet:
- Versioning of metadata and attached datasets to track changes
- Template content (and then later on other user interface decisions) which can dynamically respond/rearrange according to group/user/organisation policies stored in directories/federations such as LDAP and/or accessible using things like XACML
Secondly, we've mostly been talking about new features which is great and exciting to work on, but maybe there needs to be renewed recognition and commitment by all developers to a few consolidation steps before we launch off onto the new features:
1. Improving developer documentation - see previous posts by Clive from Software Improvements for example - a barrier to involvement and improvements is the small amount of developer documentation at least in the form of comments about why things are implemented in a particular way. I do think we need to put this in the roadmap again. Maybe we should take a two part approach to reduce the overheads of this:
(a) for new code/features: the proposal is the overall design doc
and should be updated as the proposal moves through implementation.
We could develop and enforce a policy on commenting eg. maybe some
ideas from 13 Tips to Comment Your Code (I
like the old idea that the code says what happens and the comments
say why)
(b) for existing code: continuing commitment by developers to
respond to questions on design decisions and to review commenting in
light of (a) when making changes.
An advantage of doing comments along the lines above is that we could be providing enough info for someone else to write the bulk of the developer doco! 
2. Unit tests
3. Standardizing HTML used in our XSLTs: having personally been hit by odd browser reactions to the different HTML versions used in GN, maybe we need to agree on and include a DOCTYPE so at least we all know what should be there (as was suggested by Richard from Software Improvements who ran into this as well).
Now back to getting the BlueNet MEST out and the code into the sandbox....
Cheers,
Simon