> > 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. > > 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? > > 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? > >> After the sprint we could continue working on the new stuff while >> moving 1.7.0 along to release. I think with these proposed changes... >> trunk will have to become 2.x.. Which I think makes sense because we >> are 1) breaking our disk storage format and 2) giving GeoServer a new >> face. >> >> Apologies for the long email... trying to wrap this up. If people are >> on board with this plan it would mean that at a minimum we have to get >> the following done before the sprint: >> >> 1. initial config work >> 2. fix geotools performance >> 3. finish ui evaluation >> >> I think the above list is doable... 1 is close to done and i am close >> to a patch for 2. The thing we are really lagging on at this point is >> the UI evaluation. > > So far we have an old Wicket prototype and a new Cocoon prototype. > I tried some other technologies, such as Struts2 + freemarker, but > rapidly got out of my "comfort zone", that is, they rapidly became > too annoying to use for weekend projects. > > Cheers > Andrea > > !DSPAM:4007,4820041544361015089218! >
-- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
