Saul Farber ha scritto: > 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.
The "eat your own dog food" argument is good, but I expect the REST api to have its own battery of unit and functional tests (my position atm is to vote -1 for any community module that tries to graduate without a decent testing coverage). The idea that we have to rely on a UI managed by a different group of developers strikes me as odd and risky thought. Up to this point the UI and config have been really static only because they were damn hard to modify. But that is going to change with the new code, we're no more going to stop a config change because it's too darn hard to implement. So whoever want to maintain a brand new UI is up to a fast ride. Let's assume we have "folks who want to do the front-end work figure out the best way to do that". Can we rely on them to make a change to the UI each time we change the configuration? Or should we release crippled GeoServer versions that allow new configuration to be managed only by the REST api only because the UI group did not make it? I already hear someone saying "xml + rest is ok, I don't need a UI". Lucky you that you can manage without, but please understand you're within a minority, imho most people will need a UI (heck, I know I do want one, playing by hand with xml, curl and manual url fiddling is certainly handy on occasion, but I would not want to be limited to it). Imho the default UI should be something the main, stable, guaranteed to be there development group can comfortably work on, so that the UI stays up to date as well as the REST api. If a new group of pure UI developers want to roll their own UI sitting on top of REST, make it better that the default one, and keep it up to date as GeoServer evolves, more power to them, and more power to GeoServer itself. But I'm personally against the idea of relying on a UI that I cannot work comfortably against, that is to be maintained by a "UI group" that's not there, and that has made no commitment of working on it at the same pace as GeoServer evolves. Give me the commitment needed, and then the risk may turn into an advantage: if we can rely on this group solid (be always there to update the UI before a release, not vanish in thin air after a few months) then we have more time to concentrate on the backend. Flame away ;) Cheers Andrea ------------------------------------------------------------------------- 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
