Perhaps the paradigm we are looking for is more like version control, where incremental changes are made to a body, and when happy with a complete set we tag the set.
It would be neat to be able to store and access components of configurations in a version control system or other registry infrstructure - I already use subversion for handling configs - it would be real nice to use the UI to manage just those components I want under instance control. for example, and organisation may want to deploy many services (instances of geoserver, some production WFS, soem WMS, some testbeds, some development etc) using common configuration components. When building real-world distributed systems he current UI monolithic governance model for all configuration metadata makes it worth avoiding and hand-editing in a controlled way. Rob A On Tue, Aug 5, 2008 at 7:55 PM, Andrea Aime <[EMAIL PROTECTED]> wrote: > Mike Pumphrey ha scritto: >> Would it be possible/desirable to add in a configuration option to >> "Auto-Persist?" To me, the Save + Persist model has always seemed like >> one save too many, but I do recognize its importance to people. With >> "Auto-Persist," any changes made by hitting "Save" in a config page >> would automatically persist. (As long as I'm dreaming, when this >> feature would be activated, instead of the Persist button, there would >> be a text field saving "Auto-Persist enabled," kind of like how Google >> Docs tell you that your doc is already saved.) >> >> Analogy: >> >> Pretend you were editing a text document (or sound file, or whatever). >> Imagine if hitting "Save" would save the file, but when you closed and >> reopened the program, the file became unchanged, unless you had >> additionally hit "Persist". I recognize this is a desktop metaphor, and >> so not a perfect analogy, but I'm sure there more people than just me >> out there who gets tripped up by this in GeoServer. > > Actually this is the usual web behaviour as well, when you have a db > driven app the changes are stored the moment you press submit, there > are no extra steps. > I would like a direct save me too, if we have an export/import > functionality people can always export the configuration to > back it up, and restore it in case of screw up. > > That's more easily said than done thought, since our current > config is a mess of xml and property files, but once we have > a single unified storage mechanism, why not? > > Cheers > Andrea > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
