Yeah, I think undo/redo is a cool idea, but in the desire to cut scope
I'm inclined to go with David's suggestion in the short term - just have
an 'export' or 'save as' button, so that an admin can save it at a point
that he wants. In 2.1 or something we could try out the undo/redo,
which I agree would be pretty slick.
C
David Winslow wrote:
It does seem like having 'dump entire catalog' functionality would be
useful (for migrating between different persistence mechanisms) so (for
another compromises solution) maybe we could just have a button to
download/snapshot the catalog and leave it up to the admin to handle
backup policy.
-David
Andrea Aime wrote:
Justin Deoliveira ha scritto:
I share the same concern. We do want to save along the way since we
cannot be sure there will be a clean shutdown (jvm segfaults anybody?),
so eventually on shutdown we'd just be saving whatever was already
saved the last time the config did change?
Yeah its a darned if you do darned if you don't sort of thing. On the
one hand saving when the user decides to from the ui or at shutdown
allows the ability to rollback or revert changes. Auto-saving
everytime something gets modified removes the ability to do that but
prevents loss of data when the system crashes.
I wonder if we could introduce the idea of a session (and i dont
really mean page session here) to get best of both worlds. Basically
instead of saving directly to persistence we save to a session. The
session is persisted immediately to disk whenever a change occurs. If
the user decides to save changes from the session are persisted. In
the event of a jvm crash GeoServer could detect that the session was
not saved and restore it so no work is lossed. Not sure if it will
work or its worth the effort, just a crazy idea.
So basically instead of having the DTO on top of catalog, we have their
cousins below it? ;) (ok, I understand you can store stuff in whatever
way you want, not necessarily objects).
For what it's worth, I'd just go to the direct save route. People
are working directly against databases with a lot of software, and
none of it give you the "undo/redo" ability of a desktop app without
much complaints.
Wait... what did I just say? Undo/redo huh? We _could_ in fact store
on the disk a list of commands that morph the catalog and allow
people to actually undo their changes... that would be a first for
server side apps. And of course, it assumes a single admin model, or
else, we'd have to mark changes with the user that performed them
(with the new security subsystem any user can have the ROLE_ADMNISTRATOR
role).
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://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4005,4862461838651096210785!
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
