Hello all,
Arne and I are working on a new RESTful configuration API for geoserver
datastores and featuretypes. We've added a page to the wiki at
http://docs.codehaus.org/display/GEOS/RESTful+Configuration+API so please
take a look and let us know of any concerns or questions you may have.
-David Winslow
After a brief overview, this makes a lot of sense.
Two suggestions:
1) Can you flesh out all the actions that each use-case would indicate?
Phyllis wants to keep a cluster synchronized...what are the end-to-end
actions that Phyllis would need to do, and how does each one map to a
REST-ful URI?
2) During implementation, each of these operations is really a split
thing:
a. An operation with parameters: createNewDataStore(String name,
byte content), outputStyle(String styleName, OutputStream
streamStyleToHere), etc.
b. Some REST URIs that map to each operation (along with some
interpretation that maps the URI to a specific operation)
Can you please keep a & b seperate? Some folks (like me!) might run up
against an XML gateway that LOVES soap/wsdl, but hates REST. So by
de-coupling these two steps, the geoserver team could generate a
SOAP-ified interface to the geoserver 'management API' and it wouldn't
interfere with the REST-based one, and would work for anyone that
can't/won't use REST.
--saul
On Mon, 2007-10-29 at 17:00 -0400, David Winslow wrote:
Hello all,
Arne and I are working on a new RESTful configuration API for geoserver
datastores and featuretypes. We've added a page to the wiki at
http://docs.codehaus.org/display/GEOS/RESTful+Configuration+API so please
take a look and let us know of any concerns or questions you may have.-David Winslow
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
2) During implementation, each of these operations is really a split
thing:a. An operation with parameters: createNewDataStore(String name,
byte content), outputStyle(String styleName, OutputStream
streamStyleToHere), etc.b. Some REST URIs that map to each operation (along with some
interpretation that maps the URI to a specific operation)Can you please keep a & b seperate? Some folks (like me!) might run up
against an XML gateway that LOVES soap/wsdl, but hates REST. So by
de-coupling these two steps, the geoserver team could generate a
SOAP-ified interface to the geoserver 'management API' and it wouldn't
interfere with the REST-based one, and would work for anyone that
can't/won't use REST.
Hmmm... I'm not necessarily convinced that a. could be done in a really useful way without actually having the exact use case. In my mind the stuff in a. would be a bit more generic than taking actual streams and content, and would be more part of the new config system. It might be better to code this up against this use case, and refactor appropriately when the SOAP/WSDL case comes along. Plus I feel like the SOAP/WSDL case might be better just generated from the next version of the core config objects, since there are many toolkits that do that sort of automatic generation.
Chris
--saul
On Mon, 2007-10-29 at 17:00 -0400, David Winslow wrote:
Hello all,
Arne and I are working on a new RESTful configuration API for geoserver datastores and featuretypes. We've added a page to the wiki at http://docs.codehaus.org/display/GEOS/RESTful+Configuration+API so please take a look and let us know of any concerns or questions you may have.
-David Winslow
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4005,47264c1a216286491211187!
Well, I guess I get what you're saying...that the REST-ful operations
are kind-of a 'group' of connected calls that have some actual workflow
in them. And you're seeing the SOAP based api as more of a 'low-level'
api that would expose the lower-level things than the REST-ful stuff.
I understand that, and I do agree that having a SOAP-ified part of the
new config sub-system will be great.
I guess my point is that if you're doing the:
REST-URI-call -> java method calls
work anyway, why not modularize it so you could have:
REST-URI-call \
-> modular java rep of call -> java method calls
Simulacarum SOAP-call /
I'm just hoping that you'll avoid architecting a tight binding between
REST and the actual re-configuration inside the server.
However it's done, it'll be a great addition, that's for sure!
--saul
On Mon, 2007-10-29 at 17:27 -0400, Chris Holmes wrote:
> 2) During implementation, each of these operations is really a split
> thing:
>
> a. An operation with parameters: createNewDataStore(String name,
> byte content), outputStyle(String styleName, OutputStream
> streamStyleToHere), etc.
>
> b. Some REST URIs that map to each operation (along with some
> interpretation that maps the URI to a specific operation)
>
> Can you please keep a & b seperate? Some folks (like me!) might run up
> against an XML gateway that LOVES soap/wsdl, but hates REST. So by
> de-coupling these two steps, the geoserver team could generate a
> SOAP-ified interface to the geoserver 'management API' and it wouldn't
> interfere with the REST-based one, and would work for anyone that
> can't/won't use REST.
>Hmmm... I'm not necessarily convinced that a. could be done in a really
useful way without actually having the exact use case. In my mind the
stuff in a. would be a bit more generic than taking actual streams and
content, and would be more part of the new config system. It might be
better to code this up against this use case, and refactor appropriately
when the SOAP/WSDL case comes along. Plus I feel like the SOAP/WSDL
case might be better just generated from the next version of the core
config objects, since there are many toolkits that do that sort of
automatic generation.Chris
Hi,
David and I discussed it for a bit, and we will definitely make sure our
code is as modular as possible. At this point we're not sure exactly how
much code we will actually have to write that isn't specific to the REST
interface, we will try to use the existing configuration code for all
it's worth. But stuff like autoconfiguration based on an uploaded .zip
file will live separate from the REST code.
We also intend to support JSON (2nd iteration), but that will be living
on top of the REST interface, as an alternative output format, unless
someone objects.
-Arne
Saul Farber wrote:
Well, I guess I get what you're saying...that the REST-ful operations
are kind-of a 'group' of connected calls that have some actual workflow
in them. And you're seeing the SOAP based api as more of a 'low-level'
api that would expose the lower-level things than the REST-ful stuff.I understand that, and I do agree that having a SOAP-ified part of the
new config sub-system will be great.I guess my point is that if you're doing the:
REST-URI-call -> java method calls
work anyway, why not modularize it so you could have:
REST-URI-call \
-> modular java rep of call -> java method calls
Simulacarum SOAP-call /I'm just hoping that you'll avoid architecting a tight binding between
REST and the actual re-configuration inside the server.However it's done, it'll be a great addition, that's for sure!
--saulOn Mon, 2007-10-29 at 17:27 -0400, Chris Holmes wrote:
2) During implementation, each of these operations is really a split
thing:a. An operation with parameters: createNewDataStore(String name,
byte content), outputStyle(String styleName, OutputStream
streamStyleToHere), etc.b. Some REST URIs that map to each operation (along with some
interpretation that maps the URI to a specific operation)Can you please keep a & b seperate? Some folks (like me!) might run up
against an XML gateway that LOVES soap/wsdl, but hates REST. So by
de-coupling these two steps, the geoserver team could generate a
SOAP-ified interface to the geoserver 'management API' and it wouldn't
interfere with the REST-based one, and would work for anyone that
can't/won't use REST.Hmmm... I'm not necessarily convinced that a. could be done in a really
useful way without actually having the exact use case. In my mind the
stuff in a. would be a bit more generic than taking actual streams and
content, and would be more part of the new config system. It might be
better to code this up against this use case, and refactor appropriately
when the SOAP/WSDL case comes along. Plus I feel like the SOAP/WSDL
case might be better just generated from the next version of the core
config objects, since there are many toolkits that do that sort of
automatic generation.Chris
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4038,4726537d230251961014482!
Saul Farber wrote:
Well, I guess I get what you're saying...that the REST-ful operations
are kind-of a 'group' of connected calls that have some actual workflow
in them. And you're seeing the SOAP based api as more of a 'low-level'
api that would expose the lower-level things than the REST-ful stuff.I understand that, and I do agree that having a SOAP-ified part of the
new config sub-system will be great.I guess my point is that if you're doing the:
REST-URI-call -> java method calls
work anyway, why not modularize it so you could have:
REST-URI-call \
-> modular java rep of call -> java method calls
Simulacarum SOAP-call /I'm just hoping that you'll avoid architecting a tight binding between
REST and the actual re-configuration inside the server.
Yeah, I will admit that having _way_ too many layers of indirection now probably makes me personally a bit over-hesitant about a layer between the REST binding and the configuration. I'd sorta like to see what the REST calls actually demand, and then re-architect the abstraction layer later. But I definitely see both arguments. Let's just see what David and Arne come up with, it'll just live as a community module, and then we can consider demanding a better abstraction layer if/when it moves its way in to core with a real GSIP.
Chris
However it's done, it'll be a great addition, that's for sure!
--saulOn Mon, 2007-10-29 at 17:27 -0400, Chris Holmes wrote:
2) During implementation, each of these operations is really a split
thing:a. An operation with parameters: createNewDataStore(String name,
byte content), outputStyle(String styleName, OutputStream
streamStyleToHere), etc.b. Some REST URIs that map to each operation (along with some
interpretation that maps the URI to a specific operation)Can you please keep a & b seperate? Some folks (like me!) might run up
against an XML gateway that LOVES soap/wsdl, but hates REST. So by
de-coupling these two steps, the geoserver team could generate a
SOAP-ified interface to the geoserver 'management API' and it wouldn't
interfere with the REST-based one, and would work for anyone that
can't/won't use REST.Hmmm... I'm not necessarily convinced that a. could be done in a really useful way without actually having the exact use case. In my mind the stuff in a. would be a bit more generic than taking actual streams and content, and would be more part of the new config system. It might be better to code this up against this use case, and refactor appropriately when the SOAP/WSDL case comes along. Plus I feel like the SOAP/WSDL case might be better just generated from the next version of the core config objects, since there are many toolkits that do that sort of automatic generation.
Chris
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4005,47265377230247180515871!
There are three related architectures to consider here:
1) The protocol binding (SOAP, REST, HTTP forms etc)
2) The internal architecture to separate the protocol from the action
3) the information architecture
point #3 is where, ultimately, we achieve our goals or create something that needs refactoring in a year.
For each piece of information we should be looking at where it may originate. A case in point is the definition of feature types - in the past we have tightly-coupled the persistence layer to the service - so we reflect the internal structure of files and tables etc and create an ad-hoc service for each object. This means it changes every time we optimise or extend our internal database structure, and it requires a lot of documentation to be published (somewhere!) for the end user to be able to understand it. On the other hands its easy to deploy. So we are essentially making it easy for the deployer and hard for the date user.
The converse is to implement a feature type design determined by external constraints (the community schema). In this case the user knows what its all about, and the job of the configuration is to import external resources rather than generate a lot of complex, subtle metadata.
A simple case in point, in the case of a known feature type you can import a SLD that will work for it.
I recommend we look at the WS-I.org conformance profiles concept (this is what they have found necessary to create actual interoperability with SOAP). This is basically just good practice - design the test cases first (and also consistent with design-by-contract).
Such profiles, coupled with community schemas, would result in good quality metadata becoming a simple "fill-in-the-blanks" process that would be amenable to a wizard. I think the point made about workflow and interdependencies in REST-ful operations is valid, and any solution should support complete reset, incremental update and wizard-based workflows.
FYI I'm currently working a set of SDI profiles and a spike solution for a java object library to inherit parent profiles (such as the WSI-i suite) and flatten it out into a convenient object.
I'm happy to discuss this further, and I may be able to get some time in my new job to work on the design aspects.
Rob Atkinson
Saul Farber wrote:
Well, I guess I get what you're saying...that the REST-ful operations
are kind-of a 'group' of connected calls that have some actual workflow
in them. And you're seeing the SOAP based api as more of a 'low-level'
api that would expose the lower-level things than the REST-ful stuff.I understand that, and I do agree that having a SOAP-ified part of the
new config sub-system will be great.I guess my point is that if you're doing the:
REST-URI-call -> java method calls
work anyway, why not modularize it so you could have:
REST-URI-call \
-> modular java rep of call -> java method calls
Simulacarum SOAP-call /I'm just hoping that you'll avoid architecting a tight binding between
REST and the actual re-configuration inside the server.However it's done, it'll be a great addition, that's for sure!
--saulOn Mon, 2007-10-29 at 17:27 -0400, Chris Holmes wrote:
2) During implementation, each of these operations is really a split
thing:a. An operation with parameters: createNewDataStore(String name,
byte content), outputStyle(String styleName, OutputStream
streamStyleToHere), etc.b. Some REST URIs that map to each operation (along with some
interpretation that maps the URI to a specific operation)Can you please keep a & b seperate? Some folks (like me!) might run up
against an XML gateway that LOVES soap/wsdl, but hates REST. So by
de-coupling these two steps, the geoserver team could generate a
SOAP-ified interface to the geoserver 'management API' and it wouldn't
interfere with the REST-based one, and would work for anyone that
can't/won't use REST.Hmmm... I'm not necessarily convinced that a. could be done in a really useful way without actually having the exact use case. In my mind the stuff in a. would be a bit more generic than taking actual streams and content, and would be more part of the new config system. It might be better to code this up against this use case, and refactor appropriately when the SOAP/WSDL case comes along. Plus I feel like the SOAP/WSDL case might be better just generated from the next version of the core config objects, since there are many toolkits that do that sort of automatic generation.
Chris
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Jumping into the thread a bit late.
Saul + Chris: Don't we already have a sufficient level of indirection?
The way I see it we have:
REST API -> restlet -> config objects
Adding something for SOAP should be orthogonal no?
SOAP API -> soap bindings (?) -> config objects
I must admit I am not a soap expert so someone correct me if i am wrong.
Second question is about format when doing a "PUT".. If i read things
right and based on my talk with David and Arne the other day I gather
that this will just be XML (JSON to be supported in a future iteration).
I imagine that this will be the exact same XML format that we store the
config files in currently? A couple of concerns:
Doesn't this tie us to that format for good. If we ever actually do get
a new config system implementation, the format of the underlying XML
will change. Especially if we stick with the requirement that the XML /
persistence format should not be touched directly by programmers, but
more auto generated from the java classes. Although I guess it will not
be hard to support a deprecated format... I think we should be weary of
breaking any interfaces like this though. But I guess we are going to be
breaking our underlying format so why not break the interfaces at the
same time.
But yeah... I like the interface structure. And if its just a community
module used for more of a prototype I say go for it. Although I do think
to make it into the core and something we officially release the new
config model may have to be considered a bit more. That is of course if
it ever comes that is ;).
-Justin
Chris Holmes wrote:
Saul Farber wrote:
Well, I guess I get what you're saying...that the REST-ful operations
are kind-of a 'group' of connected calls that have some actual workflow
in them. And you're seeing the SOAP based api as more of a 'low-level'
api that would expose the lower-level things than the REST-ful stuff.I understand that, and I do agree that having a SOAP-ified part of the
new config sub-system will be great.I guess my point is that if you're doing the:
REST-URI-call -> java method calls
work anyway, why not modularize it so you could have:
REST-URI-call \
-> modular java rep of call -> java method calls
Simulacarum SOAP-call /I'm just hoping that you'll avoid architecting a tight binding between
REST and the actual re-configuration inside the server.Yeah, I will admit that having _way_ too many layers of indirection now
probably makes me personally a bit over-hesitant about a layer between
the REST binding and the configuration. I'd sorta like to see what the
REST calls actually demand, and then re-architect the abstraction layer
later. But I definitely see both arguments. Let's just see what David
and Arne come up with, it'll just live as a community module, and then
we can consider demanding a better abstraction layer if/when it moves
its way in to core with a real GSIP.Chris
However it's done, it'll be a great addition, that's for sure!
--saulOn Mon, 2007-10-29 at 17:27 -0400, Chris Holmes wrote:
2) During implementation, each of these operations is really a split
thing:a. An operation with parameters: createNewDataStore(String name,
byte content), outputStyle(String styleName, OutputStream
streamStyleToHere), etc.b. Some REST URIs that map to each operation (along with some
interpretation that maps the URI to a specific operation)Can you please keep a & b seperate? Some folks (like me!) might run up
against an XML gateway that LOVES soap/wsdl, but hates REST. So by
de-coupling these two steps, the geoserver team could generate a
SOAP-ified interface to the geoserver 'management API' and it wouldn't
interfere with the REST-based one, and would work for anyone that
can't/won't use REST.Hmmm... I'm not necessarily convinced that a. could be done in a
really useful way without actually having the exact use case. In my
mind the stuff in a. would be a bit more generic than taking actual
streams and content, and would be more part of the new config
system. It might be better to code this up against this use case,
and refactor appropriately when the SOAP/WSDL case comes along. Plus
I feel like the SOAP/WSDL case might be better just generated from
the next version of the core config objects, since there are many
toolkits that do that sort of automatic generation.Chris
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,47265cab250091961014482!
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/!DSPAM:4007,47265cab250091961014482!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,47265cab250091961014482!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
David Winslow ha scritto:
Hello all,
Arne and I are working on a new RESTful configuration API for geoserver datastores and featuretypes. We've added a page to the wiki at http://docs.codehaus.org/display/GEOS/RESTful+Configuration+API so please take a look and let us know of any concerns or questions you may have.
I've read the proposal, looks good. Some considerations:
* there is no specification on the resource representation. As Justin
said elsewhere, the content of the resource really depends on what
the actual configuration is supposed to look like, so it's bound
to change when we change the the config subsystem, and every time
we change the configuration options as well.
I would also like to point out the current feature type
config is not made only of info.xml, but may also contain another file
for an overridden feature type schema, see the citewfs-1.1
configuration for an example (it's just a type override, does not
really remodels the schema).
* for feature types configuration it seems from the api you have to
"put" the info.xml file into the right path. So how do you know
what are the avaialble feature types? Maybe it's better to list
all of them and have a "active" flag to differentiate those that
are actually configured, or have a separate path that lists all
available feature types (and their structure), something like:
/api/datastore/{datastore}/availablefeaturetype/
/api/datastore/{datastore}/configuredfeaturetype/
(don't like the name but you get the idea)
* there is no mention of coverages over there?
* style editing is ok, but I think it could be a bit more ambitious
to support editing from javascript clients. You know, stuff like
exposing the structure of a style as a tree and have each part
be modifiable at will. As far as I remember Andrea Cappugi was
looking for something like this.
* for projections... incidentally I was working on a sort of
spatialreference.org clone made with restlet + gt2 srs authorities
these days. I was planning on turning it into a GeoServer community
module, so far I did not do it because it's still a bit rough along
the edges.
If you want to have a look at it I can send you the code.
As for using put to create a new projection I'm not totally
sure... wouldn't it be better to use post and have GeoServer
figure out the new epsg code?
I think asking the end user for the epsg code and then doing
a put has a high risk or rewriting an existing code instead.
Which oh, incidentally would not work on most codes, since the
EPSG database we use is read only. Only user provided codes
could be modifiable.
Long story short, the direction seems good, but I would like to
see some more details on representations.
Cheers
Andrea
The XML doesn't have to be the same that is currently used in the
configuration files, since, as you said, we're going to parse the XML
and go via the configuration objects anyway.
Any suggestions on how the XML should look are very welcome. I think
that while this is living in community, this should be considered an
experimental feature where the API can still change. Maybe the move to
core can coincide with a new config subsystem, we'll probably have
gathered enough experience to provide a good API by then.
-Arne
Justin Deoliveira wrote:
Jumping into the thread a bit late.
Saul + Chris: Don't we already have a sufficient level of indirection?
The way I see it we have:REST API -> restlet -> config objects
Adding something for SOAP should be orthogonal no?
SOAP API -> soap bindings (?) -> config objects
I must admit I am not a soap expert so someone correct me if i am wrong.
Second question is about format when doing a "PUT".. If i read things
right and based on my talk with David and Arne the other day I gather
that this will just be XML (JSON to be supported in a future iteration).
I imagine that this will be the exact same XML format that we store the
config files in currently? A couple of concerns:Doesn't this tie us to that format for good. If we ever actually do get
a new config system implementation, the format of the underlying XML
will change. Especially if we stick with the requirement that the XML /
persistence format should not be touched directly by programmers, but
more auto generated from the java classes. Although I guess it will not
be hard to support a deprecated format... I think we should be weary of
breaking any interfaces like this though. But I guess we are going to be
breaking our underlying format so why not break the interfaces at the
same time.But yeah... I like the interface structure. And if its just a community
module used for more of a prototype I say go for it. Although I do think
to make it into the core and something we officially release the new
config model may have to be considered a bit more. That is of course if
it ever comes that is ;).-Justin
Chris Holmes wrote:
Saul Farber wrote:
Well, I guess I get what you're saying...that the REST-ful operations
are kind-of a 'group' of connected calls that have some actual workflow
in them. And you're seeing the SOAP based api as more of a 'low-level'
api that would expose the lower-level things than the REST-ful stuff.I understand that, and I do agree that having a SOAP-ified part of the
new config sub-system will be great.I guess my point is that if you're doing the:
REST-URI-call -> java method calls
work anyway, why not modularize it so you could have:
REST-URI-call \
-> modular java rep of call -> java method calls
Simulacarum SOAP-call /I'm just hoping that you'll avoid architecting a tight binding between
REST and the actual re-configuration inside the server.Yeah, I will admit that having _way_ too many layers of indirection now
probably makes me personally a bit over-hesitant about a layer between
the REST binding and the configuration. I'd sorta like to see what the
REST calls actually demand, and then re-architect the abstraction layer
later. But I definitely see both arguments. Let's just see what David
and Arne come up with, it'll just live as a community module, and then
we can consider demanding a better abstraction layer if/when it moves
its way in to core with a real GSIP.Chris
However it's done, it'll be a great addition, that's for sure!
--saulOn Mon, 2007-10-29 at 17:27 -0400, Chris Holmes wrote:
2) During implementation, each of these operations is really a split
thing:a. An operation with parameters: createNewDataStore(String name,
byte content), outputStyle(String styleName, OutputStream
streamStyleToHere), etc.b. Some REST URIs that map to each operation (along with some
interpretation that maps the URI to a specific operation)Can you please keep a & b seperate? Some folks (like me!) might run up
against an XML gateway that LOVES soap/wsdl, but hates REST. So by
de-coupling these two steps, the geoserver team could generate a
SOAP-ified interface to the geoserver 'management API' and it wouldn't
interfere with the REST-based one, and would work for anyone that
can't/won't use REST.Hmmm... I'm not necessarily convinced that a. could be done in a
really useful way without actually having the exact use case. In my
mind the stuff in a. would be a bit more generic than taking actual
streams and content, and would be more part of the new config
system. It might be better to code this up against this use case,
and refactor appropriately when the SOAP/WSDL case comes along. Plus
I feel like the SOAP/WSDL case might be better just generated from
the next version of the core config objects, since there are many
toolkits that do that sort of automatic generation.Chris
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/!DSPAM:4007,47265cab250091961014482!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,47265cab250091961014482!
Well XML to Java Object binding in my experience is no easy task and
requires pretty heavyweight tools to get it right, like jaxb or emf. I
would imagine a primary goal is to keep things as simple as possible for
the client. The xml format we use the catalog and configuration now is
pretty darn simple so it might just make the most sense to stick with it
for now... and revisit this later. As you said this is an experimental
feature subject to change as implementation proceeds.
Arne Kepp wrote:
The XML doesn't have to be the same that is currently used in the
configuration files, since, as you said, we're going to parse the XML
and go via the configuration objects anyway.Any suggestions on how the XML should look are very welcome. I think
that while this is living in community, this should be considered an
experimental feature where the API can still change. Maybe the move to
core can coincide with a new config subsystem, we'll probably have
gathered enough experience to provide a good API by then.-Arne
Justin Deoliveira wrote:
Jumping into the thread a bit late.
Saul + Chris: Don't we already have a sufficient level of indirection?
The way I see it we have:REST API -> restlet -> config objects
Adding something for SOAP should be orthogonal no?
SOAP API -> soap bindings (?) -> config objects
I must admit I am not a soap expert so someone correct me if i am wrong.
Second question is about format when doing a "PUT".. If i read things
right and based on my talk with David and Arne the other day I gather
that this will just be XML (JSON to be supported in a future iteration).
I imagine that this will be the exact same XML format that we store the
config files in currently? A couple of concerns:Doesn't this tie us to that format for good. If we ever actually do get
a new config system implementation, the format of the underlying XML
will change. Especially if we stick with the requirement that the XML /
persistence format should not be touched directly by programmers, but
more auto generated from the java classes. Although I guess it will not
be hard to support a deprecated format... I think we should be weary of
breaking any interfaces like this though. But I guess we are going to be
breaking our underlying format so why not break the interfaces at the
same time.But yeah... I like the interface structure. And if its just a community
module used for more of a prototype I say go for it. Although I do think
to make it into the core and something we officially release the new
config model may have to be considered a bit more. That is of course if
it ever comes that is ;).-Justin
Chris Holmes wrote:
Saul Farber wrote:
Well, I guess I get what you're saying...that the REST-ful operations
are kind-of a 'group' of connected calls that have some actual workflow
in them. And you're seeing the SOAP based api as more of a 'low-level'
api that would expose the lower-level things than the REST-ful stuff.I understand that, and I do agree that having a SOAP-ified part of the
new config sub-system will be great.I guess my point is that if you're doing the:
REST-URI-call -> java method calls
work anyway, why not modularize it so you could have:
REST-URI-call \
-> modular java rep of call -> java method calls
Simulacarum SOAP-call /I'm just hoping that you'll avoid architecting a tight binding between
REST and the actual re-configuration inside the server.Yeah, I will admit that having _way_ too many layers of indirection now
probably makes me personally a bit over-hesitant about a layer between
the REST binding and the configuration. I'd sorta like to see what the
REST calls actually demand, and then re-architect the abstraction layer
later. But I definitely see both arguments. Let's just see what David
and Arne come up with, it'll just live as a community module, and then
we can consider demanding a better abstraction layer if/when it moves
its way in to core with a real GSIP.Chris
However it's done, it'll be a great addition, that's for sure!
--saulOn Mon, 2007-10-29 at 17:27 -0400, Chris Holmes wrote:
2) During implementation, each of these operations is really a split
thing:a. An operation with parameters: createNewDataStore(String name,
byte content), outputStyle(String styleName, OutputStream
streamStyleToHere), etc.b. Some REST URIs that map to each operation (along with some
interpretation that maps the URI to a specific operation)Can you please keep a & b seperate? Some folks (like me!) might run up
against an XML gateway that LOVES soap/wsdl, but hates REST. So by
de-coupling these two steps, the geoserver team could generate a
SOAP-ified interface to the geoserver 'management API' and it wouldn't
interfere with the REST-based one, and would work for anyone that
can't/won't use REST.Hmmm... I'm not necessarily convinced that a. could be done in a
really useful way without actually having the exact use case. In my
mind the stuff in a. would be a bit more generic than taking actual
streams and content, and would be more part of the new config
system. It might be better to code this up against this use case,
and refactor appropriately when the SOAP/WSDL case comes along. Plus
I feel like the SOAP/WSDL case might be better just generated from
the next version of the core config objects, since there are many
toolkits that do that sort of automatic generation.Chris
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,47265cab250091961014482!
!DSPAM:4007,472742e9198567180515871!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Andrea Aime wrote:
David Winslow ha scritto:
Hello all,
Arne and I are working on a new RESTful configuration API for geoserver
datastores and featuretypes. We've added a page to the wiki at
http://docs.codehaus.org/display/GEOS/RESTful+Configuration+API so please
take a look and let us know of any concerns or questions you may have.
I've read the proposal, looks good. Some considerations:
* there is no specification on the resource representation. As Justin
said elsewhere, the content of the resource really depends on what
the actual configuration is supposed to look like, so it's bound
to change when we change the the config subsystem, and every time
we change the configuration options as well.
I would also like to point out the current feature type
config is not made only of info.xml, but may also contain another file
for an overridden feature type schema, see the citewfs-1.1
configuration for an example (it's just a type override, does not
really remodels the schema).
Thanks, and yes, we're very open to suggestions on how the feature
should be described. As a first approximation we intended to mimic the
configuration files, but we'll be happy to change that if people come up
with suggestions.
* for feature types configuration it seems from the api you have to
"put" the info.xml file into the right path. So how do you know
what are the avaialble feature types? Maybe it's better to list
all of them and have a "active" flag to differentiate those that
are actually configured, or have a separate path that lists all
available feature types (and their structure), something like:
/api/datastore/{datastore}/availablefeaturetype/
/api/datastore/{datastore}/configuredfeaturetype/
(don't like the name but you get the idea)
If you go to api/datastore/{datastore} you should see a list of links to
information associated with the datastore, and if you click the link to
api/datastore/{datastore}/featuretype you see a list of the feature
types. I am not sure whether we should offer additional views based on
namespaces. These pages are rendered in XHTML, so that it can easily be
inspected with a normal browser. However, we haven't considered the
distinction between active and available feature types, so we need to
learn more about that.
* there is no mention of coverages over there?
That will come very soon, we omitted them so that people could start
discussing our proposal, but it will be there from the start.
* style editing is ok, but I think it could be a bit more ambitious
to support editing from javascript clients. You know, stuff like
exposing the structure of a style as a tree and have each part
be modifiable at will. As far as I remember Andrea Cappugi was
looking for something like this.
I am not sure this makes sense, or maybe the SLD files I wrote were just
poor. It seems to me that in many case you will want to modify every
branch of the SLD? Like when you change the color of a feature, you
probably want this to happen at every resolution.
* for projections... incidentally I was working on a sort of
spatialreference.org clone made with restlet + gt2 srs authorities
these days. I was planning on turning it into a GeoServer community
module, so far I did not do it because it's still a bit rough along
the edges.
Yes please 
If you want to have a look at it I can send you the code.
As for using put to create a new projection I'm not totally
sure... wouldn't it be better to use post and have GeoServer
figure out the new epsg code?
Yes, you are right.
I think asking the end user for the epsg code and then doing
a put has a high risk or rewriting an existing code instead.
Which oh, incidentally would not work on most codes, since the
EPSG database we use is read only. Only user provided codes
could be modifiable.Long story short, the direction seems good, but I would like to
see some more details on representations.Cheers
Andrea-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4038,47270b2b125332090977483!
Arne Kepp wrote:
Andrea Aime wrote:
David Winslow ha scritto:
Hello all,
Arne and I are working on a new RESTful configuration API for geoserver datastores and featuretypes. We've added a page to the wiki at http://docs.codehaus.org/display/GEOS/RESTful+Configuration+API so please take a look and let us know of any concerns or questions you may have.
I've read the proposal, looks good. Some considerations:
* there is no specification on the resource representation. As Justin
said elsewhere, the content of the resource really depends on what
the actual configuration is supposed to look like, so it's bound
to change when we change the the config subsystem, and every time
we change the configuration options as well.
I would also like to point out the current feature type
config is not made only of info.xml, but may also contain another file
for an overridden feature type schema, see the citewfs-1.1
configuration for an example (it's just a type override, does not
really remodels the schema).
Thanks, and yes, we're very open to suggestions on how the feature
should be described. As a first approximation we intended to mimic the
configuration files, but we'll be happy to change that if people come up
with suggestions.
The other thing we have in there, that people may want pretty soon, is the templates for KML description and time stuff.
Though it's overkill for now, I wonder if eventually we might want the concept of a 'parent' feature type that things could inherit from, like it'd use their metadata and kml templates and the like.
* for feature types configuration it seems from the api you have to
"put" the info.xml file into the right path. So how do you know
what are the avaialble feature types? Maybe it's better to list
all of them and have a "active" flag to differentiate those that
are actually configured, or have a separate path that lists all
available feature types (and their structure), something like:
/api/datastore/{datastore}/availablefeaturetype/
/api/datastore/{datastore}/configuredfeaturetype/
(don't like the name but you get the idea)
If you go to api/datastore/{datastore} you should see a list of links to
information associated with the datastore, and if you click the link to
api/datastore/{datastore}/featuretype you see a list of the feature
types. I am not sure whether we should offer additional views based on
namespaces. These pages are rendered in XHTML, so that it can easily be
inspected with a normal browser. However, we haven't considered the
distinction between active and available feature types, so we need to
learn more about that.
Yeah, this distinction was one of the things I was thinking about as well. So right now, by default in the UI, if you configure a datastore none of its featureTypes are published. You have to go to the featureType page and make a default style, get the SRS and bounds. And hopefully you also fill out other metadata, like actual information about the data - abstract, keywords, ect, that crawlers can use and search on.
As for a separate path vs a flag, I think it depends on if 'active' is just a property, or if it's a different resources.
One way to handle it, which hits on something that I'd like to see, is a resource that's just:
/api/data/
And it would list all the configured featureTypes and Coverages. Though perhaps we should wait until we get the AtomPub implementation, since that should also have the ability to list such things, and then to get at the actual data.
So I'm leaning to just having an 'active' flag. I think it'd also be helpful to be able to create a new datastore and have it by default make all its feature types active (or at least all that it could). Perhaps at that step we could make the user supply metadata that they'd all inherit. But in general we can derive enough automatically in most cases that we shouldn't need to require doing lots of stuff to activate.
In turn if a featureType is missing a CRS or has something that really does prevent us from activating it we should have the REST interface reject turning it active unless they configure it.
* there is no mention of coverages over there?
That will come very soon, we omitted them so that people could start
discussing our proposal, but it will be there from the start.* style editing is ok, but I think it could be a bit more ambitious
to support editing from javascript clients. You know, stuff like
exposing the structure of a style as a tree and have each part
be modifiable at will. As far as I remember Andrea Cappugi was
looking for something like this.
I am not sure this makes sense, or maybe the SLD files I wrote were just
poor. It seems to me that in many case you will want to modify every
branch of the SLD? Like when you change the color of a feature, you
probably want this to happen at every resolution.
I'd like to see what code he came up with. For now I think it'll be a big win just to be able to put and get styles.
One question that wasn't clear from the api - is listing and putting styles based on their filename? Or the actual 'name' of the SLD? Or an arbitrary name? I guess the current thing is an arbitrary name, but it should be noted that SLD's have a 'name' parameter.
I suppose now's not the time to rearrange the messy styling backend.
But I think what I might recommend is to also allow a post to api/style/ that then derives the name of the style from the 'name' portion of the SLD.
One last question - singular vs. plural for lists?
I was thinking it'd be /api/datastores/ and /api/styles/ instead of /api/datastore/ and /api/style/ Thoughts?
But yeah, this is looking quite nice, I'm excited.
Chris