> 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.
(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 >>> >>> >>> >> >> > > > !DSPAM:4007,48619c55109111804284693! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
