Re: Issue 13.6: Discard changes

[Phil Shafer <phil@juniper.net>]

Andy Bierman writes:
>The part that says the #candidate config should
>be implicitly locked whenever somebody writes to it.

I follow you now, but I think there's a distinction
between an inability to acquire a lock and an implicit
lock, though this may be a fine point.

The objective is to control the interaction between
the user and any applications.  If there are uncommitted
changes, a lock cannot be granted without hosing
the human user, which isn't a viable option.

>We should not make huge exceptions in the architecture 
>based on scenarios involving a human at the CLI

We _have_ to make whatever exceptions are required to handle scenarios
involving humans at the CLI.  The human has to win any user.vs.automation
contest.  You cannot hose the user.  Ever.

Give the user an application that hoses him and you'll be making
an application that the user doesn't use.

Thanks,
 Phil

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>