Luca Morandini ha scritto: > Justin Deoliveira wrote: >> I can see a couple of benefits. It could possibly reduce the download >> size if we wanted to release the webapp separately. Which may be >> something to consider once we have a good REST api. Or perhaps users who >> have a set data directory which does not really change do not have a >> need for the UI? I would be interested in hearing feedback on this one. > > I'm not a GeoServer committer, but I cannot help giving my 2(euro)c: > > I think an admin UI should be sort of on afterthought, even a separate > webapp. > Let's face it: UI are intrinsically volatile and diverse (AJAX, > Accessible i.e. non-Javascript, CLI, etc.), while the underlaying > (RESTful?) API is much more stable (if well-designed, that is).
I'm not sure about the stableness, at least for the next year to come. The REST API gives you access to the underlaying configuration. Now, for the past 1.5 years we've been delaying all non sponsored configuration changes because it was too painful to make them. This means we piled up a lot of them. When a more usable UI and a more usable configuration are in place, we'll have to start addressing all of those complaints and start making available all those extra control knobs we refused to add, meaning that for quite some time the REST api outputs will be very unstable (the overall architecture of the REST API may not change much, but the documents returned and required for updates will change a lot imho). > That would be akin to CMSes, which use to separate repository from the > front-end. > > So, my idea would be to first build the API, then (or concurrently) the > admin UI. > This would have a couple benefits: > 1) Helping the developer adding a new service to focus on the API, not > the UI, possibly resulting in a better API. > 2) Decreasing the GeoServer footprint in production environment, by > dropping the UI baggage (and increasing security). This idea of making the UI a separate web application worries me. So far we've tried to be the champions of the "easy to use", at least for the first step, the getting started ones. Having to deploy a separate application to configure GeoServer seems to go in the opposite direction? > Of course, this may cause a different pace of development of services > code and UI code, but there would always be the option of using Ant (or > even wget) to use a newly-added service API in a CLI fashion. Which is exactly what I wish to avoid, a situation where you have to use non friendly tools because developers did not have time to develop a usable UI (which is already happening btw with sld and freemarker templates, I find both of them very painful to work with and a major shortcoming of the current GeoServer value proposition). Cheers Andrea ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
