Re: RFI: Database URIs

On Nov 26, 2013, at 11:49 AM, Gisle Aas <[email protected]> wrote:

> There is also precedence for using "+" in scheme names.  Something like "db+postgresql:" then.  It's still cluttered, and not really compatible with what other have used.  Or "x-postgres:" while it's still experimental.  Naming stuff is hard.

Oh, I thought URI didn’t like +, but it turns out it is okay with it.

    $ perl -MURI -E 'say URI->new("x-ssh+foo://example.com")->scheme'
    x-ssh+foo

Cool. Downside: Each DB engine requires its own scheme, which would make formal registration rather a PITA. I do see some registered “hierarchical” schemes using a dot, though, e.g., iris.beep, iris.xpc, etc.:

  http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

Surely someone has done this before, though. :-(

Yeah, naming is hard. Probably why it’s one of my favorite things to do. :-)

> I don't know.  Version 2 of the mysql protocol perhaps.  I saw it at https://github.com/kennethreitz/dj-database-url/blob/master/dj_database_url.py#L17

Well, if it’s a real thing, I’m happy to add it.

> The scheme really should just be named after the protocol, not the kind of product you happen to find at the other end.

But scheme != protocol. [Wikipedia](http://en.wikipedia.org/wiki/URI_scheme) says:

> URI schemes are frequently and incorrectly referred to as "protocols", or specifically as URI protocols or URL protocols, since most were originally designed to be used with a particular protocol, and often have the same name. The http scheme, for instance, is generally used for interacting with web resources using HyperText Transfer Protocol. Today, URIs with that scheme are also used for other purposes, such as RDF resource identifiers and XML namespaces, that are not related to the protocol. Furthermore, some URI schemes are not associated with any specific protocol (e.g. "file") and many others do not use the name of a protocol as their prefix (e.g. "news").

To me it makes sense not to tie it to a particular protocol. I want to connect to a database, and don’t much care about the protocol. The PostgreSQL libpq URL starts with postgresql://, not libpq://.

> Is sqlite:///path relative or absolute then?  What about sqlite:/path?

Both are absolute. sqlite://path and sqlite:path are both relative. This is how my implementation handles them.

> dj-database-url claims 4 slashes is the way to go; sqlite:////path

Wow, is that ugly.

I was relying on the standard for file: URLs as the precedent.

> The ftp: standard had the same problem.  It was once specified that ftp://server/%2Fpath was to be required to make the path absolute, while ftp://server/path was supposed to be relative to the home directory you ended up in after logging in to the ftp account.  This was very confusing to users so most browers just implemented the path to always be absolute, with no way to access relative paths. That's at least how I remembered it.

%2f is ugly. Of course, there is no host name in file: URIs. If we add it, as would be needed for Firebird, for example, I can see why dj-database-url ended up with four slashes: This is a full path:

    db:firebird://example.com//path/to/db

So I guess these should be equivalent:

    db:firebird:////path/to/db
    db:firebird:/path/to/db

The first has an empty string for the network location, the second has no network location part at all. I’ve just committed a fix to support this.

  https://github.com/theory/uri-db/commit/cd60c7ac7e02572e5db3b39d2acb08b4a7fcfefe

Best,

David