I'm not familiar with eXist; however, it looks like there are a few
reasons why it wouldn't work as well as custom Restlets for our needs.
* Not all of the resources we are exposing correlate 1:1 to XML
documents in the Data directory. For example, modifying
featuretype configurations may result in modifications to both a
catalog file and a per-featuretype configuration file. There is
also discussion about unifying the 'coverage/featuretype'
distinction into a more user-friendly 'layer' abstraction.
* We want to allow extensions to add RESTful endpoints to GeoServer
* We provide more than just XML as a representation format.
Currently this is just JSON and HTML, but all the apps I know of
that are using GeoServer's REST interfaces right now are using
JSON as preferable to XML (since they are JavaScript apps :) ).
If you want to elaborate further on why eXist would do well here, please
do. But keep in mind we're doing a bit more than just editing XML
documents over the web.
Thanks for the input!
-David Winslow
Chris Thatcher wrote:
> David Winslow wrote:
>> Andrea Aime wrote:
>>
>>> David Winslow ha scritto:
>>>
>>>> Hey all, just a heads-up that I caught and fixed a typo in the main
>>>> security context. If you're using the rest module in community,
>>>> updating will cause your application to require authentication for
>>>> non-GET requests. That is, if you are using Restlet to provide web
>>>> services under the {gs_context}/rest/ path, GET requests are
>>>> unrestricted while PUT/DELETE/POST requests require authenticating
>>>> with either ROLE_ADMINISTRATOR or ROLE_AUTHENTICATED. If you would
>>>> like to adjust these restrictions, you can edit
>>>> applicationSecurityContext.xml in main.
>>>>
>>>> This affects trunk and the 1.6.x branch.
>>>>
>>> Nice to have those in place, but imho bad that you need to unpack
>>> a jar in order to configure those. Any chance we can have a
>>> rest.properties file (or something like that) in the data directory
>>> instead?
>>> Is the configuration done at the resource path level or
>>> something an "all or nothing"?
>>> out there.
>>> Cheers
>>> Andrea
>>>
>>>
>>>
>>>
>>
>> Yes, it's kind of lame that these need to be configured all in one place
>> right now. However, I wonder whether it makes sense in the long run to
>> have per-path restrictions at all. What we really care about securing
>> is various aspects of the configuration, and data, right? If we allow
>> accessing these from multiple paths (ie, the RESTful WFS versus the
>> traditional form, the config interface vs. the config API) then
>> path-based restrictions are going to be confusing and make it easy to
>> leave gaping security holes, so maybe it's better to just leave it out
>> entirely?
>>
>> -David
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
> I suspect that I might be providing controversial advice here (plus Im
> new to the list) but why are you reinventing the wheel with ReST?
> Using an embedded eXist engine would provide 98.6% of your restful
> interface requirements, plus 300% additional options. I'm assuming
> your requirements include resource level permission management similar
> to a unix file system... This is certainly a can of worms and I'm
> willing to play devils advocate on behalf of embedded exist, given
> that it's an additional library, open source or not. (PS if you keep
> up with eXist you'ld also know it's supporting very important ReSTful
> protocols like Atom Publishing as well as some geo spatial indexing
> from google-summer-o-code sponsored projects.) I'm not suggesting
> that an xmldb replace existing datasource support, only that you can
> use eXist internally in a webapp at runtime in such a way that ReST
> becomes a much more natural development strategy.
> $0.02
>
> Chris Thatcher (And thanks for the awesome software!)
>
> !DSPAM:4040,483d057a105375332866982!
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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/
>
> !DSPAM:4040,483d057a105375332866982!
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
> !DSPAM:4040,483d057a105375332866982!
>
-------------------------------------------------------------------------
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
