Hey-
Andrea Aime wrote:
>
>> My vision is that you create a new workspace (say a database
>> connection) doing something like the following - excuse the shorthand:
>>
>> Request:
>> POST /geoserver/workspaces/
>>
>>
>> Response:
>>
>>
>> Then you want to see what layers (term layers used flexi
Hey-
David Winslow wrote:
> It seems like this is confusing the user interface and the api a bit, right?
> Wouldn't we want translat(ed|able) verbs for the UI but HTTP method names for
> the actual body?
>
Yeah, I agree. Either way. There's a whole lot to be decided on in
terms of body str
Hey-
David Winslow wrote:
> 4. Have a perfect one-to-one mapping between namespaces and the rest api,
> such
> that the rest api can just be another way of editing services.properties.
...
> I am currently a fan of option 4; have each 'map' in the rest API be
> a 'namespace' for the services
So Andrea pointed out to me that this restful security interface would be
showing up fairly soon after a security configuration option that's
currently 'in the works'. The current conception of how it will work is to
have a list of rules of the form:
..=
where each field can be a * to indicate
It seems like this is confusing the user interface and the api a bit, right?
Wouldn't we want translat(ed|able) verbs for the UI but HTTP method names for
the actual body?
It also seems to me that, for most resources, you're either adding/deleting
stuff from it OR modifying it, not usually bot
Hey-
Chris Holmes wrote:
> Since we're going for more intuitive for users, I'm not convinced that
> http verbs for permissions are intuitive for users. Read and Write are
> a lot more intuitive to a naive me then PUT, POST, GET, and DELETE. If
> we wanted that granular I'd suggest Write, Crea
Since we're going for more intuitive for users, I'm not convinced that
http verbs for permissions are intuitive for users. Read and Write are
a lot more intuitive to a naive me then PUT, POST, GET, and DELETE. If
we wanted that granular I'd suggest Write, Create, Read and Delete
(Remove?). I
Hey-
Should be a new thread, but what the heck...
Andrea Aime wrote:
> There is no plan to have per feature or per property access control
> (think restricted areas, or data columns that only certain users can
> see) at the moment.
>
> REST wise, this could be represented as:
> /worskspaces//la
Hey all, thanks for the discussion, I'm liking the direction a lot. I
think the map concept is potentially very powerful. We do need to
figure out how namespaces fit in, but I think I too am inclined to have
them not so central to the rest api. To have them more as a parameter
on a featureTy
Hey-
Andrea Aime wrote:
>
> Namespaces are today the only organisational structure we have in
> GeoServer, each datastore and coveragestore is placed under a certain
> namespace, and will be soon used to drive per layer security restrictions.
> Unfortunately namespace by itself is not strong eno
doh, trying to catch up on the thread...
On Thursday 27 March 2008 05:34:07 pm Andrea Aime wrote:
> Justin Deoliveira ha scritto:
> >> It certainly makes code easier than trying to fake what's not there.
> >> That said we have already quite a bit of indirection levels, adding one
> >> more won't k
Tim Schaub ha scritto:
> Thanks for the thoughts Andrea.
>
> I'll respond in even smaller bits
>
> Andrea Aime wrote:
>> Btw, I noticed now that the proposal page does not have the concept
>> of a datastore, that is, one of a connection to a database, remote wfs
>> server, or a file (and the same
Hey-
Andrea Aime wrote:
>
> Since we're a WFS server namespaces can't really be removed or
> completely hidden, you have to be able to reference the same layer the
> same way across services (using wms and wfs at the same time is not
> uncommon).
>
> OGC tests ask for multiple namespaces no?
>
> Well, since geotools datastore do not attach namespaces to feature types
> but to the datatsore as whole, I thought you might have wanted to wrap
> the FeatureSource to change the namespace of each single layer on the
> fly. That would be an extra indirection, an extra wrapping.
> How did you
Thanks for the thoughts Andrea.
I'll respond in even smaller bits
Andrea Aime wrote:
> Btw, I noticed now that the proposal page does not have the concept
> of a datastore, that is, one of a connection to a database, remote wfs
> server, or a file (and the same goes for coverages).
>
> If you're
Justin Deoliveira ha scritto:
>>
>> It certainly makes code easier than trying to fake what's not there.
>> That said we have already quite a bit of indirection levels, adding one
>> more won't kill us.
>> It just seems unecessary to me. We could just change the wording
>> and call namespace worksp
>
> It certainly makes code easier than trying to fake what's not there.
> That said we have already quite a bit of indirection levels, adding one
> more won't kill us.
> It just seems unecessary to me. We could just change the wording
> and call namespace workspaces,folders,bags,whatever and keep
David Winslow ha scritto:
> On Thursday 27 March 2008 11:46:11 Andrea Aime wrote:
>> David Winslow ha scritto:
>> ...
>>
>>> Just to clarify, my current conception of the security configuration for
>>> the new REST API is to have permissions for the /maps hierarchy apply to
>>> the map data, and pe
Justin Deoliveira ha scritto:
>
>> Technically namespace is an attribute of the datastore, not of the
>> layer, and there's not much we can do about it, unless we do change
>> the datastores in gt2.
>> So if workspace == datastore, then the structure has to be
>>
>> {namespace}/{workspace}/...
>>
On Thursday 27 March 2008 11:46:11 Andrea Aime wrote:
> David Winslow ha scritto:
> ...
>
> > Just to clarify, my current conception of the security configuration for
> > the new REST API is to have permissions for the /maps hierarchy apply to
> > the map data, and permissions for the /workspaces h
David Winslow ha scritto:
> On Thursday 27 March 2008 05:14:13 Andrea Aime wrote:
>> Tim Schaub ha scritto:
>> ...
>>
>> 2) I think it makes sense to have one set of resources related to
>>> configuring data (workspaces) and one set related to publishing layers
>>> (maps). The name "workspaces" ca
> Technically namespace is an attribute of the datastore, not of the
> layer, and there's not much we can do about it, unless we do change
> the datastores in gt2.
> So if workspace == datastore, then the structure has to be
>
> {namespace}/{workspace}/...
>
> because of how gt2 is done.
That
David Winslow ha scritto:
...
> Just to clarify, my current conception of the security configuration for the
> new REST API is to have permissions for the /maps hierarchy apply to the map
> data, and permissions for the /workspaces hierarchy would apply to
> configuration (maybe you have a set o
Justin Deoliveira ha scritto:
> My thoughts on this one are that we should treat namespace as an
> attribute on layer, and not as a grouping of layers.
Technically namespace is an attribute of the datastore, not of the
layer, and there's not much we can do about it, unless we do change
the datas
On Thursday 27 March 2008 05:23:52 Andrea Aime wrote:
> Tim Schaub ha scritto:
> ...
>
> > 4) I also don't know squat about auth/auth in GeoServer, but it seems to
> > me like it would be pretty handy to expose a "groups" resource (and/or
> > "roles") next to the users resource. Then every other r
On Thursday 27 March 2008 05:14:13 Andrea Aime wrote:
> Tim Schaub ha scritto:
> ...
>
> > 2) I think it makes sense to have one set of resources related to
> > configuring data (workspaces) and one set related to publishing layers
> > (maps). The name "workspaces" captures the meaning of a resour
My thoughts on this one are that we should treat namespace as an
attribute on layer, and not as a grouping of layers. I also dont think
namespace makes it into the "workspace" hierachy either. I would like to
see it be something seperate:
GET geoserver/namespaces/ (get a list of namespaces)
GET
On Thursday 27 March 2008 04:55:27 Andrea Aime wrote:
> Wow, lots of stuff. I'll try to answer each item in its own
> mail since I have the impression this will generate quite a thread ;)
>
> Tim Schaub ha scritto:
> > Hey-
> >
> > I'd be interested to hear thoughts on an architecture proposal for
>
> I like the idea of a single consistent REST api that goes from
> configuration to actual data.
> A user interface based on the same structure (that is, one that
> is completely based in rest style, that is, simply return back HTML
> as the default resource encoding) may be appealing, thought
Tim Schaub ha scritto:
> 5) We're currently doing some work on style configuration. I like the
> idea of having a collection of styles at /geoserver/styles and then
> assigning named styles to layers through the
> /geoserver/maps//layers//styles resource. The styles could
> have a short name
Tim Schaub ha scritto:
...
> 4) I also don't know squat about auth/auth in GeoServer, but it seems to
> me like it would be pretty handy to expose a "groups" resource (and/or
> "roles") next to the users resource. Then every other resource (with
> the exception of individual features perhaps) c
Tim Schaub ha scritto:
...
> 2) I think it makes sense to have one set of resources related to
> configuring data (workspaces) and one set related to publishing layers
> (maps). The name "workspaces" captures the meaning of a resource for
> the configuration of layer collections a bit better fo
Wow, lots of stuff. I'll try to answer each item in its own
mail since I have the impression this will generate quite a thread ;)
Tim Schaub ha scritto:
> Hey-
>
> I'd be interested to hear thoughts on an architecture proposal for
> GeoServer:
> http://geoserver.org/display/GEOSDOC/GeoServer+Res
Hey-
I'd be interested to hear thoughts on an architecture proposal for
GeoServer:
http://geoserver.org/display/GEOSDOC/GeoServer+Resources
This builds off of work that David Winslow has been doing and has
written up here:
http://geoserver.org/display/GEOSDOC/RESTful+User+Management+API
http://
34 matches
Mail list logo
