Hi all, > Thinking more about this, we could have a way to have the best of both > worlds. We can factor out the base model which totally uncouples any > data loading operations from the object model.
I really like this solution, because it solves the basic problem the GSIP was created for, while avoiding the massive updates in geoserver code. I can look into this to find out for its feasibility (hope we won't have any multiple inheritance probs here). Ciao, Emanuele Alle 21:56:36 di giovedì 25 febbraio 2010, Justin Deoliveira ha scritto: > Thinking more about this, we could have a way to have the best of both > worlds. We can factor out the base model which totally uncouples any > data loading operations from the object model. > > And then in geoserver main continue to maintain interfaces that extend > the base model and add the specific methods for loading data. That would > keep everything backwards compatible and prevent the need for a mass > change. > > -Justin > > 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 -- ------------------------------------------------------- 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
