I'm having a little trouble with this proposal. It does state its motivation, but it's not terribly concrete. Can you fill this out with some more specific examples of what's being held back here, for those of us that aren't close to the catalogue, or have Justin's comments exhausted those?
Mark Leslie Geospatial Software Architect LISAsoft ------------------------------------------------------------- Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009 ------------------------------------------------------------- LISAsoft is part of the A2end Group of Companies http://www.ardec.com.au http://www.lisasoft.com http://www.terrapages.com Justin Deoliveira wrote: > I have stated my feedback to this proposal before but I will reiterate > here for the sake of public discussion. > > In general I am against this idea. I understand that from an > architectural stand point it makes things cleaner, but practically I > think it has more cons than pros. > > For instance, this proposal requires that all "data access" methods: > > FeatureTypeInfo.getFeatureType() > DataStoreInfo.getDataStore() > ... > > Be removed outright from the catalog classes. This has multiple downsides: > > 1) It requires a massive update to the geoserver code base > 2) It makes interacting with the catalog more difficult > > For (2) it means that one has to instead of : > > featureTypeInfo.getFeatureType() > > now have to: > > Catalog catalog = ... > catalog.getResourcePool().getFeatureType(featureType) > > The new way of access requires one to maintain a reference to the > catalog or the resource pool (which in some cases might be unavailable) > and it also makes resource pool part of the primary api when it should > really be an implementation detail imo. > > One of the motivations for the proposal is that it makes backing the > catalog onto hibernate easier. I am not sure I see this. Every data > access method on a bean just forwards to catalog.getResourcePool(). So > all is required is that whatever is unmarshaling the catalog objects > have a way to set a reference to the catalog on beans. Which I don't see > as an overly burdensome requirement. > > The other is to allow external applications to have a geoserver model of > the catalog. Which yes would make it easier. But the only hypothetical > use case presented is for a java REST configuration client, for which > one has already been implemented in community. > > Apologies for coming across as so negative, it is just my opinion that > the potential benefits do not out weight the potential downsides. I > could be convinced otherwise but I think the proposal requires some more > concrete examples of where the current architecture does not work. But > that said I am not PSC so I can't vote -1, but as someone who is "close" > to the catalog api I thought I should voice my opinion. > > -Justin > > On 2/25/10 7:41 AM, Emanuele Tajariol wrote: >> Hi all, >> >> I created a GSIP about a refactorization of the catalog beans. >> You can find it at >> http://geoserver.org/display/GEOS/GSIP+45+-+Moving+GeoServer+model+in+a+standalone+module >> >> Here's a little excerpt from the proposal: >> ============================== >> At the moment, when an external app needs to exchange data with a >> GeoServer >> instance (e.g.: via REST or by accessing a DB-based catalog), it has to >> re-define its own set of beans representing Stores, Resources, Styles and >> so >> on. >> >> It could be extremely handy if external applications could use the very >> same >> *Info beans used by GeoServer (both interfaces and related >> implementations). >> >> In the present architecture this cannot be accomplished without importing >> in >> the external app all the catalog logic, that is useless outside a complete >> GeoServer instance. >> >> All in all, this refactoring will make clear the boundaries of metadata >> objects, making the creation of modules for marshalling/umarshalling them >> much simpler. >> ============================== >> >> Ciao, >> Emanuele >> >> >> ------------------------------------------------------- >> Ing. Emanuele Tajariol >> >> GeoSolutions S.A.S. >> Via Carignoni 51 >> 55041 Camaiore (LU) >> Italy >> >> phone: +39 0584983027 >> fax: +39 0584983027 >> >> http://www.geo-solutions.it >> http://geo-solutions.blogspot.com >> ------------------------------------------------------- >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Geoserver-devel mailing list >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
