I agree with Luca on this one. I think "eating our own dog-food" is the surest and best way to properly develop and constantly test the REST api. Plus it puts all gui's on a level playing field.
FlexJSON + the config back-end + REST for configuration would seem to allow everyone to just get on with developing the core engine, while letting folks who want to do the front-end work figure out the best way to do that...and keep it seperate. --saul On Tue, 2008-05-06 at 11:21 -0700, Jody Garnett wrote: > 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 ------------------------------------------------------------------------- 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
