On Mon, 23 Jul 2012, Nick Daly wrote:
Does anybody have thoughts on logical error handling behavior? Some of the
existing Plinth code (eg, hostname changer) would try to revert changes when
they failed; i'm not sure if that behavior should be implemented at the
exmachina (library/wrapper) level or left to application logic.
Thinking about this, I'd like to know how Ex does two things:
1. Whether changes are atomic (how do we prevent the system from
seeing a semi-changed state?).
Currently this is left to the application logic (separate set/save calls).
I'll need to check if Augeas rolls back commits to multiple files if one
of the files fails.
2. Whether failed changes aren't implemented.
It seems like the least surprising behavior would be: if Ex can't save
the changes, it rolls them back and raises an error. That way, the
system's never left in an undefined state, and the controlling
application can decide whether to give it another go or just bail.
I meant at a higher level: the configuration file is saved, but restarting
services depending on that configuration file fails. The easy solution
with minimal surprise is to bubble up the service restart error message
and wait for the user to reconfigure before restarting the service.
Rolling back changes could result in large amounts of user-entered data
being lost because of a small typo.
Some firmwares (pfSense) also implement a "test configuration" feature
which reverts new changes after two minutes unless they are re-confirmed;
this helps prevent bricking or user lockout due to misconfiguration. I
think this is overkill for now.
-bryan
_______________________________________________
Freedombox-discuss mailing list
Freedombox-discuss@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
