Probe using OPTIONS

[Vincent Ladeuil]

>>>>> "Jelmer" == Jelmer Vernooij <jelmer at samba.org> writes:

    Jelmer> Hi Vincent,

    Jelmer> As we discussed during UDS, I'd like to add a
    Jelmer> mechanism that allows bzr-svn to do an OPTIONS
    Jelmer> request before the probing of the smart server using
    Jelmer> a POST request to .bzr/smart hits in.

We talked about that already and Andrew didn't agree and, AIUI,
this is still the main reason for your friendly fork of bzr.

    Jelmer> So far I've done this by moving the bzr-svn check
    Jelmer> before the bzr smart server one. This is a bit
    Jelmer> hackish and it also means that the results of the
    Jelmer> OPTIONS request done by bzr-svn are lost. ISTM the
    Jelmer> OPTIONS result would also be useful for
    Jelmer> e.g. bzr-webdav?

Nice try but no cigar :-) I can't see how webdav will use it and
it would have to be cached at the transport level which we don't
share AFAIK. But trying to share information about the server
during the probe sounds like a good idea.

    Jelmer> Would it make sense to allow control formats to probe
    Jelmer> based on the OPTIONS reply ?

I think the whole probe design should be clearly exposed so we
can start to discuss its pro/cons more generally.

In UDS Andrew seemed convinced that the smart server probe should
stay in place.

You clearly have a use case where it breaks the user experience.

The best we can do so far is to introduce some config variable
(presumably in authentication.conf since it targets remote
server) to disable the smart server on a case-by-case basis.

I also remember your objections about that approach: even if we
provide *by default* configurations for some well known servers,
new ones can (and will) appear.

Both bzr-svn and the smart server want to avoid a useless round-trip.

First I'll note that serverS exist *today* for which that useless
round-trip won't be avoided with the actualS solutions (for
bzr-svn OR the smart server).

Things are even more uncomfortable for bzr-svn users since they
are prompted for credentials even for read-only operations.

So unless there is some way to issue a single request that both
bzr-svn and the smart server (and some others ?) can *share* to
learn about the server abilities to talk to them, we are in a
dead-end.

ISTM that Andrew had an explanation about why the smart server
couldn't use OPTIONS but I can't remember the details (more
configuration on the server side maybe ?).

Is that a fair summary ?

   Vincent