Re: [Monotone-devel] Time for 0.99

[Richard Levitte]

In message <address@hidden> on Sun, 24 Oct 2010 22:56:16 +0200, Thomas Keller 
<address@hidden> said:

me> Am 24.10.10 15:43, schrieb Richard Levitte:
me> > In message <address@hidden> on Sun, 24 Oct 2010 12:47:11 +0200, Thomas 
Keller <address@hidden> said:
me> > 
me> > me> > po/sv.po: 1315 translated, 68 fuzzy, 135 untranslated messages.
me> > me> 
me> > me> No changes here.
me> > 
me> > I've been ill for a while (10 days or so).  A heavy cold.  I'm just
me> > now starting to come out of it.
me> > 
me> > me> 1) Our buildbot infrastructure still does not work (Richard...?). I'd
me> > 
me> > See my excuse above ;-)
me> 
me> No problem, good to have you back :)
me> 
me> > me> 2) I have an yet unfinished hack sitting in my workspace which should
me> > me> provide better compatibility towards RFC 3986 (yes, the URI issue). 
I'll
me> > me> hopefully fix and commit that within the next one or two days.
me> > 
me> > Hmm, maybe I've missed something, what issue is there still?
me> 
me> I had a deeper look at the referenced RFC this is the outcome:
me> 
me> a) I agree we should not treat the slash between the authority and the
me> path as part of the path. I fixed that in my code already.

Actually, although I argued for that interpretation while talking on
IRC, I then changed my mind after having re-read the RFC.  After all,
it very clearly has this:

      The generic URI syntax consists of a hierarchical sequence of
      components referred to as the scheme, authority, path, query,
      and fragment.

      URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

      hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty

Note how, when there's an authority present, the path has to be
absolute or empty (within the realm of the scheme, of course)?

(see http://www.apps.ietf.org/rfc/rfc3986.html#sec-3)

me> b) Its stupid to force people into typing up to four slashes for the
me> file: protocol. The file: protocol is the protocol we currently support
me> that allows to have no authority; likewise it - the file: protocol - may
me> have an authority by definition, but we do not support that anyhow, so
me> we could easily make a special case for that. The RFC also states that
me> an URL with an authority has always a relative or no path, so things
me> like file://// look rather dubious to me and I don't want to make this
me> the default for our use cases.

Yeah, I agree that it seems silly, and the way I've read the RFC, it's
not even RFC compliant to have file:////...

What we do that's rather silly, though, is that we currently require
the use of a explicit authority part?  The RFC doesn't require that.
On the other hand, the RFC requires the presence of a scheme, which we
do not, to be able to parse the old server address syntax
(ADDRESS[:PORT]).  However, if we do what we do today (parse for the
old syntax first, then try to parse the string as a URI), it should
really be safe to require a scheme...  in essence, we have to; either
that or require an authority part.  Otherwise, the following string
will always be a problem:

  mtn:22/bar

(is that the scheme "mtn" with the path "22/bar" or the host "mtn"
with the port "22" and the path "/bar"?  Note that RFC 3986 allows
periods in scheme names...)

If we require a scheme to be present for a string to be a valid URI,
the problem string above will not be a problem any more.

me> c) I'd like to achieve RFC 3986 compliance, i.e. it should be a
me> no-brainer for people to find out how URIs work in monotone just because
me> they're used to them in countless other applications. I still like to
me> make it as easy as possible for them to type them in  though - and that
me> means that I don't want to force them into typing "mtn://" for default
me> network actions each time. The URI scheme should be clear and helpful,
me> not a burden to type for the user (no browser forces you to type http://
me> in front of an URL, right?). If this means special hacks in the URI
me> code, then I'm up to do them.

Yeah...  what I see most do is to pick out what they can parse as
host[:port] and try to see if that's a valid host (is it a valid
host on the local machine?) and port (is it a number?) combo, and fly
with that.  If that doesn't work, try to parse it as a URI following a
strict syntax (has to start with a scheme).  If that doesn't work,
tuck a default scheme at the front ("mtn:") and try to parse it as a
URI following a strict syntax.  If that doesn't work, fail the parse.

me> d) During the reading through RFC 3986 I found other minor bugs in our
me> URI handling, for example the RFC states that the authority should be
me> handled case insensitive, which practically means it should be
me> lowercased, so code.monotone.ca, CODE.monotone.CA and coDe.monotone.Ca
me> can all use the same acknowledged server cert.

Uhmmm, the RFC states that the host should be case-insensitive, not
the whole authority part.

me> Yes, always the evening :) Thursday sounds fine to me as well. I really
me> just want to get my ass off and do it not much later than that, because
me> more and more people are bitten by the SQLite 3.7.3 bug, which might
me> force us to do a 0.48.2 if it takes much longer.

We might want to do that anyway, so people can do an easy upgrade to
fix that problem without having to evaluate all the other changes.

Cheers,
Richard

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish