[RFC] Proof-of-Concept suggesting correct remote break-lock url (bug #250451)

[Andrew Bennetts]

Jonathan Lange wrote:
> On Sun, Jul 5, 2009 at 10:47 AM, Andrew
> Bennetts<andrew.bennetts at canonical.com> wrote:
> > Wouter van Heyst wrote:
> > [...]
> >>  * it requires a new protocol version
> >
> > FWIW, It doesn't require a new protocol version if I'm skimming this
> > correctly — it's true that old clients will give an ugly “Unexpected error
> > from server” message if they get a LockWait error, but I think that's
> > tolerable.  It's not like the existing behaviour is great either...
> >
> > If that isn't tolerable we can add newer versions of the *.lock_write verbs,
> > and only transmit LockWait for those.
> >
> 
> What do you think about the check for
> 'lockdir._DEFAULT_TIMEOUT_SECONDS == 0' to determine if we're on the
> remote side? Is there a nicer way of doing that?

That's not a bad trick, although I believe the test suite also sets that, which
may be an issue.

Ideally perhaps you'd check the way the logging is set up, which should be
different on a remote side (random warnings should not be sent to stderr, there
ought to be some sort of access.log and server-error.log or similar...), but
unfortunately there's no difference in logging yet.

As a tiny step in the right direction, I think it would be ok for cmd_serve to
explicitly set a global flag somewhere that this patch could then check.  (The
test suite, at least the blackbox tests, would then need to take care to reset
it, of course.)

-Andrew.