Andrea Aime wrote: > 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? Correct, events are thrown for every addition, removal, and modification of any "configuration" object. > 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. Yeah... depends on how we do it. As you say if we serialize in one shot it could lead to a huge file that needs to be read back in. Off the top of my head what might work well is to keep the separation we have today between the catalog.xml and individual info.xml files per feature type. That coupled with lazy loading should lead to some good results. > 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. Unfortunately not as implemented currently. Having to maintain total backwards compatibility with the UI has forced us to mimic the way things work today. > > 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. Interesting... I am not sure I quite understand the use case. However at first glance I think i prefer making this functionality of the security system: being able to specify read access on a layer to specific groups. Rather then add a special type of layer which implies some access control constraints. > > Anyways, just some food for thought > Cheers > Andrea > > !DSPAM:4007,4836caf1149873327367457! >
-- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
