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.