deegree3 developer meeting 2008-05-28
Protocol by: Andreas Schmitz
Participants: Alexander Padberg, Rutger Bezema, Markus Schneider, Oliver Tonnhofer, Christian Kiehle, Andreas Poth, Andreas Schmitz
Contents
1. Property files for i18n
The original idea was to have three kinds of property files for i18n as follows:
- file_langcode.properties with the translations
- file_description.properties with a description usable for mapping the keys to a speaking description
- file_classes.properties with a mapping of keys to classes where they are used (automatically generated)
and to edit these files with the prbeditor. As some developers are not at ease with the tool and there are some technical difficulties using something different than the standard "property resource bundle"-conventions, it was agreed to use a different approach.
We ask the PSC to decide the further steps and make the following suggestion: we invest some time to write a custom GUI tool and invent a new file format to simplify the handling of i18n in deegree3 and related projects, including custom translation of the messages by users.
2. Processing framework
The implementation of the processing part in deegree3 is finished and based on the Quartz framework as planned. The usage of the Identifiable interface (as discussed at the last meeting) introduced a discussion about the purpose of the Identifiable interface.
3. Identifiable/Identifier
There are three options:
use an Identifiable interface and make all custom identifiers implement it
use an Identifier implementations that all modules that need an identifier will use
- implement a custom identifier wherever it's needed and adapt it to the custom needs
After a heated discussion it became clear that there is no consensus on what's the best way here. Disagreement about a core "component" is always a bad thing, so it was decided to remove the current Identifiable interface, and use the third option for future needs of an identifier. Rutger will do the job of removing the current implementation and references to it.
4. Internal databases
In deegree2, there is a need for an "internal" database (ie, a database that's not an external program) such as HSQLDB or JavaDB in components such as the WMPS. In deegree3, there will also be a need for such a library, for example the processing framework will need one for making jobs persistent.
HSQLDB was used in deegree2 and has the advantage, that the entire database is written to a SQL file and can thus be easily edited. The JavaDB (a.k.a Derby) database has the advantage, that it is included since Java 1.6 (only in the JDK) and will probably be integrated further in Java 1.7 (deegree3 will be based on Java 1.7).
The functionality and ease of use seems to be similar for both softwares, so it was decided to check up on the integration status for JavaDB in Java 1.7 before making a final decision on which one to use.
5. Java 1.7
There are already beta versions of Java 1.7. A few month ago, they were not ready yet for productive use. If there is a new beta, it was decided that we try it once more, so we can use it as a standard for the development of deegree3 if it works better.
6. Versioning of services/request parsing etc.
A big problem of request parsing in deegree2 were always different versions for the same service. There are some points to consider when trying to solve this problem:
- make bean classes that can encapsulate everything the different versions define
use a ServiceLoader that dynamically searches for fitting classes able to answer a specific version
- use an XML/other configuration file that maps the version to the class that handles it
- use a request parser per version
While discussing how to best solve this problem, we also discussed the general scheme of request handling (especially XML requests):
choose which service is requested, based upon the XML namespace --> find out which version was used when requesting --> parse the actual request --> handle the request
Special care needs to be taken for the response as well, especially for GetCapabilities requests.
In deegree2, we have several parsers for specific capabilities versions of services. Since most of the time one is only interested in a small part of the answer to a GetCapabilities request, this is not really necessary to be implemented for deegree3. A little number of xpath expressions are often enough to extract the needed information. Parsing full capabilities documents also means that broken (invalid) documents cannot be handled, which decreases interoperability. To make handling of capabilities documents easy, one can implement a helper class that loads the capabilities document, evaluates xpaths or extracts specific information (for example the GetMap HTTP GET URL).
The capabilities response documents can be generated on the fly. Most of the information is usually clear from the context (deegree knows which FilterCapabilities it supports) or from the configuration. It is also planned to use more defaulting for unimportant information (from the technical point of view) such as contact information etc.
7. Roadmap
It is becoming a little clearer what will be the next steps in deegree3.
- What's planned to be finished within 2008:
- a minimal implementation of the Sensor Observation Service (SOS)
- a Web Coverage Service (WCS)
- a Web Feature Service (WFS)
- the deegree object model
- What's planned to be finished during the first half of 2009:
- a new web based client (iGeoPortal)
- the new desktop client (iGeoDesktop)