On Nov 26, 2013, at 11:49 AM, Gisle Aas <gi...@activestate.com> 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
