Justin Deoliveira ha scritto: > Hi all, > > Here is the newest version of the configuration GSIP for your reading > pleasure. > > http://geoserver.org/display/GEOS/GSIP+8+-+New+Configuration+System > > Questions/comments/feedback welcome. It would be nice to be able to vote > on this in next weeks IRC meeting.
Just adding two extra bits before I forget them, thought they are not strictly related to this phase of the configuration subsystem overhaul. First, the granularity of modifications and storage. I believe this proposal, in his full blown implementation, will trigger specific events, like "datastore x created", "featuretype y configured" instead of the current, dump, "catalog changed" event. Correct? I also hope we'll have a good storage granularity, that is, we'll have to try and make sure we just save what's strictly necessary, avoiding to store the whole catalog in a single shot, which may become an expensive operation when hundreds of feature types are configured. Finally, is the resource pool maintained accordingly, that is, avoiding to drop and recreate all datastores like we do now, at great expense of time, especially for some datastores like SDE? At the same time it would be wise to remove datastores from the pool if removed from the configuratin, since some of the cached objects (connection pools) are scarce resources. The second thing that popped up to mind is that it would be nice to have "hidden" layers, that is, feature types that are configured, available, but not advertised along with capabilities. This idea comes from the frequent users request to have transient layers built from views and to be mainly used on a user by user basis. I believe the use case calls for a layer that's not advertised to the whole world... well, in fact it would be nice to have it available only when a certain user is making the requests, but this seems quite a bit harder. If the user is authenticated, it would be possible to have the security subsystem handle it, but I'm sceptical the vast majority of apps would want to rely on the GeoServer security subsystem... thought with a good REST api to manage users and security it could become a viable solution. Anyways, just some food for thought Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
