Hey- Jumping in a bit late here, but I'll add one perspective from the client side.
> On 3/4/10 10:06 AM, Andrea Aime wrote: >> Justin Deoliveira ha scritto: ... snip... >>> * Default datastore >>> >>> I was thinking that it would be nice to add a concept of a default >>> data store to a workspace, just like we have the concept of a default >>> workspace. >>> >>> And like workspaces we add a "symbolic link" called "default" which is >>> accessible via http GET/POST/PUT. For example: >>> >>> ... snip... >>> Or perhaps just rely on all the server defaults: >>> >>> POST http://.../workspaces/default/datastores/default/featuretypes/ >> >> Scratch scratch. I'm having a hard time getting why the >> default is important (I hesitantly mentioned it in my first >> mail because it was something that was in the air about this work). >> I agree with Justin below. It would be nice to be able to "jump start" a client by configuring it with a well known location for posting a new feature type config (reducing the HTTP requests it takes to derive this location). In the simplest case, the data store name (or type) is an detail that a client shouldn't have to worry about. Perhaps this gets to the resource/publishing split, but eventually it would be nice to be able to expose a feature collection as a resource and *not* have the resource location change when the underlying store changed (e.g. /layers/states/1 would get me the same feature whether the data admin decided to store it in a directory of shapefiles or a database). Tim >> The reason I have for having the default workspace is to allow people >> to avoid fixing layer names in OWS requests. >> What is the reason for having a default store? Avoiding to remember >> its name when doing REST calls, building a client that just does >> not know anything about existing workspaces and stores and still >> be able to create a layer? >> > Yeah to make things easier on the client. Perhaps the client does not > care where the new data layer ends up in the workspace / datastore > hierarchy. Or maybe the admin does not want the client to know because > they want the freedom to change it. > > All the client wants is a place to create new layers. In this case it > would be nice to not have to burden the client with (a) knowing ahead of > time what the default workspace and datastores are or (b) having to > parse through configuration to find out dynamically what they are. > > Anyways, a hypothetical use case to be sure so not a strong argument. It > would be nice to have the input of a client side developer who would be > building an application against this functionality. -- Tim Schaub OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
