I do like the idea of perhaps moving the "I/O" methods to Catalog. But I would handle this as as a subsequent step. First do the pure refactoring, then improve the interface. I fear mixing the two will inevitably lead to behavior changes which will lead to regressions.
2c. -Justin On 2/26/10 4:49 PM, Gabriel Roldan wrote: > Hi, > just to chip in with my 2 cents. > > To start with, I totally agree that: > 1- *Info objects should be decoupled from the "data" objects. > 2- ResourcePool should be an implementation detail > > So no catalog.getResourcePool().getFeatureType(typeInfo), but > catalog.getFeatureType(featureType). Remove the > Catalog.getResourcePool() method. > > But, in order for such a patch to be acceptable, it should be a > _straight_ refactoring, meaning absolutely no change in behavior other > than replacing the typeInfo.getFeatureType() by > catalog.getFeatureType(typeInfo) kind of calls. > > My 2c. > > Gabriel > > On 2/25/10 9:05 AM, 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 >> >> > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ 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
