I was planning on taking the latest for a spin but looking over the
interface it looks good to me. Regarding the iterator and not being
closable i wonder if utilizing the recent addition for GSIP69 of
ClosableIterator which is used in the Catalog interface. Could be nice to
be consistent with that api.
https://github.com/groldan/geoserver/blob/GSIP69/src/main/src/main/java/org/geoserver/catalog/util/CloseableIterator.java
https://github.com/groldan/geoserver/blob/GSIP69/src/main/src/main/java/org/geoserver/catalog/Catalog.java#L1714
On Wed, Aug 29, 2012 at 6:59 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> Hi,
> been working on CSW on the GeoServer side, it would be nice if someone
> could provide
> some checks on the interface chosen to represent the service.
>
> Here is its:
>
> https://github.com/geoserver/geoserver/blob/master/src/community/csw/csw-core/src/main/java/org/geoserver/csw/CatalogService.java
>
> The methods represent as usual the various CSW methods, plug
> GetRepositoryItem
> which is an extra method added by the ebRIM profile (and which we don't
> need to
> support unless there is a CatalogStore providing support for it).
>
> The capabilites method returns a CapabilitiesType instead of a
> TransformerBase,
> meaning we are building the in memory EMF representation of the caps
> document
> and that we are going to encode it with XSD.
> The reasons for this are:
> - the caps document is limited in size
> - the various profiles introduce a number of extra content in the caps
> document that
> is literally sprinkled around in the operations and service metadata
> as opposed to being in a well specified root element, so having a object
> to play
> against makes it easier to perform open ended additions
>
> The "decoration" could be done in a DispatcherCallback, but I guess it's
> nicer if we provide
> people a pluggable CSWCapabilitiesDecorator interface with a single
> decorate(CapabilitiesType)
> method where the extra bits are added.
>
> DescribeRecord would return a list of FeatureType objects, each
> representing one type
> of record (csw:Record, ISO and ebRIM).
> Encoder wise I don't think we are going to turn the above into XML schema,
> especially
> since the normal DescribeRecord response contains links to external
> schemas as opposed
> to a full in-line description, and they are pretty much static from what
> I've seen.
> Again, I expect to have a pluggable extension point that can encode the
> subset of the
> response relative to a certain well known record type, this time playing
> within the
> xml transformer framework (the one used for the capabilties documents of
> WMS/WFS/WCS
> and to generate KML).
>
> getRecords and getRecordById would return the Feature representation of
> records.
> Again the response will be delegated to specific encoders that know how to
> deal with
> each particular record type, and again using the translator framework
>
> GetDomain needs to return a list of possible values for a specific request
> parameter or a specific
> record type. Needless to say, this list might be very long, so for the
> time being I've chosen
> Iterable<String> as the return type, which would then be managed by a
> translator
> to encode the xml response.
> I'm not 100% happy with the choice in that an Iterable does not have a
> close method
> and does not throw exceptions, so I don't see it playing well with
> database backed
> lists...
> Another option could be to return a SimpleFeatureCollection or a
> FeatureIterator...
> it seemed a bit heavy handed to return something as big as SimpleFeature
> just
> to hold a string though...
>
> GetRepositoryItem returns a RepositoryItem object, which is really just a
> struct containing
> an input stream (the contents) and its mime type.
>
> Harvest and Transaction are using full EMF objects on both sides: I don't
> plan to implement
> them now (Niels might want to implement Transaction, not sure) but believe
> the interface
> should work for the needs of these operations.
>
> Opinions?
>
> Cheers
> Andrea
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 962313
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
