Changes between Version 65 and Version 66 of Bolsena2010

Timestamp:

May 18, 2010, 4:50:20 PM (14 years ago)

Author:

heikki

Comment:

--

Bolsena2010

@@ -63 +63 @@
  || 41 || ||Configuration ||The way that !GeoNetwork handles timeouts to remote requests is not configurable. Action: In GeoNetwork, timeout on remote requests e.g. WMS, should be configurable via the administration interface.|| heikki: 2 ||
  || 42 || ||Project management / sandbox strategy||Developments in "sand boxes" are not pushed back into the trunk in a timely manner. Action: The PSC should publish and enforce tighter processes relating to sandboxes. If possible, all sand box developments should be pushed back into the trunk in a predetermined time period (this should be a condition of being granted permission to set up a sandbox). If the sand box feature can't be pushed into the trunk because the trunk code doesn't have the capability (e.g. Pluggable profiles, pluggable skins) then priority should be given to developing that capability in the trunk so that the sand box feature can be included into the trunk (relates to project management comment/observation above). || heikki: 1 ||
- || 43 || ||Customization||!GeoNetwork is not distributed with multiple skins and it does not allow pluggable skins. Action: !GeoNetwork should be released with multiple skins that can be optionally selected and are pluggable. These skins should be easily modified for an organisation’s needs and not be contained within the XSL or Java code. || ||
- || 44 || ||Installer / Application server||There is no (installer) option to choose Tomcat as an alternative to Jetty. Comment: The current situation reflects GeoNetwork’s origins, particularly its funding bodies. Adding Tomcat and supporting it would require fixing some current defects - a good thing. But it would be a lot of work to maintain it, in particular, it would significantly increase the time required for testing and release preparation. Action: !GeoNetwork should use the existing BlueNet MEST Tomcat configuration to provide an option within the installer to choose Tomcat instead of Jetty as the servlet container.  Jetty should continue to be the default. || ||
- || 45 || ||Parent/child policy ||Parent/child/sibling bidirectional navigation for metadata records Finding the parent or child of given record is painful Action: Use of parent/child/sibling metadata records in the search results as a way to cope with varying levels of record granularity. For example, listing all children under the parent and presenting this within a collapsed tree GUI component.  Perhaps provide a way to limit results to only parents and toggle this option on/off. || ||
+ || 43 || ||Customization||!GeoNetwork is not distributed with multiple skins and it does not allow pluggable skins. Action: !GeoNetwork should be released with multiple skins that can be optionally selected and are pluggable. These skins should be easily modified for an organisation’s needs and not be contained within the XSL or Java code. || heikki: 3 ||
+ || 44 || ||Installer / Application server||There is no (installer) option to choose Tomcat as an alternative to Jetty. Comment: The current situation reflects GeoNetwork’s origins, particularly its funding bodies. Adding Tomcat and supporting it would require fixing some current defects - a good thing. But it would be a lot of work to maintain it, in particular, it would significantly increase the time required for testing and release preparation. Action: !GeoNetwork should use the existing BlueNet MEST Tomcat configuration to provide an option within the installer to choose Tomcat instead of Jetty as the servlet container.  Jetty should continue to be the default. || heikki: 4 ||
+ || 45 || ||Parent/child policy ||Parent/child/sibling bidirectional navigation for metadata records Finding the parent or child of given record is painful Action: Use of parent/child/sibling metadata records in the search results as a way to cope with varying levels of record granularity. For example, listing all children under the parent and presenting this within a collapsed tree GUI component.  Perhaps provide a way to limit results to only parents and toggle this option on/off. || heikki: 3 ||
  || 46 || ||Search||Community is seeking a way to deal with varying granularity of metadata records, such that fine scale records don’t swamp fewer broad scale records. Many fine scale records (highly granular) make the metadata system more powerful (useful).  Being forced to limit granularity only as a work around for basic search result presentation/visualisation would be a shame. || ||
- || 47 || || Vocab / Thesaurus||Support for external vocabulary services Vocab services are becoming more common and an ability to connect to a custodians vocab service would be beneficial and reduce duplication and creation of stale vocabs/ thesauruses in GN. Action: An interface is required to query for vocab definitions from external sources. || ||
+ || 47 || || Vocab / Thesaurus||Support for external vocabulary services Vocab services are becoming more common and an ability to connect to a custodians vocab service would be beneficial and reduce duplication and creation of stale vocabs/ thesauruses in GN. Action: An interface is required to query for vocab definitions from external sources. || heikki: proposes OWL/ebRIM integration, see [http://geonetwork.tv/owl/ http://geonetwork.tv/owl/] ||
  || 48 || ||Reusable Objects || Reusable (Controlled) Objects, allow fields to be reusable. Currently, if a user were to enter multiple records, for each record that user would have to re-enter “owner” their details. Worse, if that person’s details were to change, they remain the same in old records for which they have edited. The person’s details should be held as a managed object for which all records reference. This would allow the updating of details be reflected in each record that uses them - see the fragment harvesting of contact info above.|| ||
  || 49 || ||HTTPS support || HTTPS support. Currently all logins to !GeoNetwork are going unsecured through HTTP and the GN configuration doesn’t allow the use of HTTPS enabling account sniffing attacks.|| ||