Justin Deoliveira wrote: > >> I was thinking of reusing as much as possible for the XStream >> backend. If the current backend is going to use XStream for >> persistence anyway then that doesn't mean much :) But yes, I had >> 'reusable for alternative implementations' in mind there, as opposed >> to 'reusable by other subsystems,' which I was taking for granted as >> a design goal. > OK, still not sure I 100% understand but yes :). I do think that we > should structure it in a way that we don't add any dependencies from > the core model on xstream, so that we could swap out other persistence > backends easily. Ah, got it now. I had been thinking persistence mechanisms would require reimplementing the entire catalog but it could probably be done in most cases with just loaders and change listeners, leaving the in-memory objects to be shared across implementations. I wonder, though, whether a 'store everything on shutdown' policy is necessary/useful if we are saving all changes that are meant to be saved along the way. I suppose it would be useful for 'export configuration' functionality as well.
-David > > (I also >> wonder whether (some subset of) the Catalog API could be used for a >> Java client API for RESTConfig. If done right, this could allow a >> network of GeoServers to share configuration transparently (configure >> one to save to a real persistance mechanism, and the rest just sync >> with it via REST) and be Quite Nifty.) > Yeah I had the same thought. I think it could work. All the "client" > really needs is the core catalog and config model which is pretty > isolated from the rest of GeoServer. > > Having a persistence backend based on this client and actually stores > config on another GeoServer is a great idea. I think Chris brought > this up a while ago. > >>>> >>>> 4. It seems like the new Catalog API is both Important and >>>> Complicated. I wonder therefore whether we should start working on >>>> a test suite for Catalog implementations codifying all the weird >>>> expectations we have for it. A decent start would probably be to >>>> go over the current *ImplTest's and try to split off the ones that >>>> are testing implementation details from the ones that are testing >>>> the intended behavior; we could add tests as intended behavior >>>> proves ambiguous. >>> I don't see it all that likely that another implementation will be >>> coming along all that soon due to how non-trivial it would be. >>> During the prototyping of this new api we tested two >>> implementations. The first was the "in memory" implementation >>> currently on trunk. The second was a catalog backed onto hibernate. >>> So the interface and paradigm did hold up against two radically >>> different implementations. >>> >>> But I definitely agree that having tests against the interface >>> itself and against the implementation should be separated. And if we >>> do get another implementation i suspect it will be mandatory. >>> >> Thanks for the quick response. >>>> >>>> -David >>>> >>>> ------------------------------------------------------------------------- >>>> >>>> Check out the new SourceForge.net Marketplace. >>>> It's the best place to buy or sell services for >>>> just about anything Open Source. >>>> http://sourceforge.net/services/buy/index.php >>>> _______________________________________________ >>>> Geoserver-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>>> >>>> >>>> >>> >>> >> >> >> >> > > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
