Jody Garnett wrote: >> Well the way I see it going is that the rest stuff will be rewritten >> against the new configuration classes. I dont think it will be too much >> to switch over... and we can still keep the rest of the code base >> againast the old model... and things will still be in sync. >> > I like that plan - make only the new config model available via the REST API. > It gets the new config model some time in front of developers and gives us a > real motivation to switch the remaining modules over (ie so they can be seen > by programmers that > are using the REST API). > I have been talking this over with a co-worker (Martin Davis - perhaps you have heard of him). He had a couple ideas, one of which is bad but I will share anyways... basically he wondered if we could "eat our own dog food" with respect to the REST API backing onto the new config subsystem. Wither a javascript or wicket application (ie separate application) that communicates to the core geoserver module using the REST API.
I personally hate the idea of writing our own javascript front end (sure we could do it; but it would be a maintenance and testing hassle). I am not too sure of the idea of making a Wicket application that fires changes over to geoserver via the a REST api ... but it gives me an idea. Could we use Andrea's spring remoting magic, publish the same config API out via REST and via spring remoting (for a separate Wicket application?). I am not sure if this idea holds any appeal. It may be a bad product idea to introduce a REST API as a distinct layer; it would be way too easy make new functionality quickly via REST and forget to keep the web client up to date and in sync. Jody ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
