So in Tuesday's meeting we figured out the scope for Geoserver 1.7, renaming this subject line to match ... Andrea Aime wrote: > 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. > Thanks for expressing my concern so clearly Andrea, I think a good way to proceed is ... 1. Set up a user interface, wicket was the last man standing that met the requirements I was interested in 2. Use the user interface to hammer out the configuration layer 3. Start to roll out only the methods we love in the configuration layer via the REST API so external scripts can be written
The alternative, making a JavaScript user interface would involve making a lot of REST API for functionality that is already captured by GeoTools DataStoreFactory ... and I am not sure where such a quest would end? Would we by extension get a REST API that covers 30% of GeoTools? Scary .... Making a separate war, implemented in Java or Groovy I guess, is also an option; even for low level services like sharing DataStores we could register a few shared services using JNDI and let the user interface WAR have access to the running GeoServer. I cannot quite remember what the attraction to Groovy was? ie why was it floated around as part of the user interface discussion? 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
