Justin Deoliveira ha scritto: >> >> Hmmm. REST api is going to finally free all the people that are >> struggling trying to programmatically configure GeoServer, so it's >> cool all right. >> But (you expected a but, right?) how do we implement a good REST api >> like http://geoserver.org/display/GEOSDOC/GeoServer+Resources without >> a correspondent big change in the configuration and config storage >> subsystem? > 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 thought you wanted to get rest stuff on 1.7.x before branching (whilst writing stuff directly against the new config would be trunk business?). Moreover, are the concept of map and workspace covered in the new configuration api? >> >> If we go for a cut down version of that proposal, it might work, but we >> have to be careful to make it forward compatible. There are issues >> to be solved there too (such as style treatment which is incompatible >> with the current geoserver config). > Not quite sure I understand... fyi I did change the style class in the > new model so its compatable with the old way. Is that what you mean? I did not look at the moment. I'm looking that that REST proposal that does still call style a FeatureTypeStyle. The current configuration (and imho any sane usage) should use UserStyle directly, instead of splitting it into feature type styles.... Maybe I'm just misunderstanding, I thought you wanted to implement that proposal on top of the current configuration classes before branching. But I am confused anyways, since I don't remember seeing a few concepts like "map" in the new config eiher (which in that proposal does represent not only a layer grouping, but a stand alone wms/wfs server no?) >> >> Yeah, doing both seems quite ambitious. It might work if we just try >> to do a UI technology conversion without trying to redo the UI face >> as well, and spend the extra time making the UI talk to the new config >> module directly. Of course, this would not really give GeoServer and >> new face, but then again, I don't think we can handle changing the >> config, UI technology and UI face at the same time. >> Moreover, giving GeoServer a new face would require some planning on >> what the new workflow is, and that would put extra burdern on the >> preparation or turn the sprint into a discussion of how the new UI >> should look like. > How exactly would this work? Would we reuse the jsp's or something like > that? Or just mock up something similar to what we have until we really > research what would be a good UI workflow? Mock up something similar to what we have now, yes. Otherwise we have to decide what the new UI would look like as well, make a plan for a better workflow. If we have one week only and a new technology I don't think we'll also have the time to discuss and design a new workflow and new look for the UI... Cheers Andres ------------------------------------------------------------------------- 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
