Toward A Database URI Standard

http://theory.so/rfc/2013/11/26/toward-a-database-uri-standard/

by mariuz • 13 years ago

46 25 13 years ago

theory.so

lwf• 13 years ago

Publish an RfC.

steveklabnik2• 13 years ago

Yes, this. It's the proper way to communicate standards in the internet community.

I'd be much more comfortable following an RFC than a blog post.

justtheory7• 13 years ago

This blog post is soliciting feedback on the general idea before I go and do the work of submitting a formal RFC. For all I know, someone could have shot it down. Just think of this as step 1 toward the development of an RFC.

zzzeek• 13 years ago

Everything was great here until the post suggested...let's have two formats? All the examples mentioned (one of which is my own) use a strict RFC-1738 style, and the "//" is required, including for filesystem paths. RFC-1738 already provides the spec and as all the linked examples illustrate, it's all we need. Why the second format omitting the so-called "authority part"?

edit: wow rfc1738 is like two rfcs ago, we're up to rfc3986 now. rock!

sp3322• 13 years ago

For sqlite, there isn't really a host name. It's just a file path. What would that look like if you could only use the first format?

PeterWhittaker• 13 years ago

Would it not be

file:///path

as per RFC 1738?

thepicard• 13 years ago

The different examples are all pretty much just different ways of writing the same thing. And then another different way of writing the same thing is presented, with "db:" prepended. Huh.

The only thing that is substantially different between any of these is the engine/protocol/adapter/whatever section. Perhaps that field should always refer to the protocol type and not the driver, but I consider that problem pretty negligible.

lobster_johnson• 13 years ago

The db: prefix must (according to the article) always be there. What he's describing is the URI part, which follows RFC 3986. It's not two formats, just one: db:<URI>.

justtheory7• 13 years ago

Yes, but for convenience (and compatibility with other proposals), I think it would be okay for a given implementation to recognize well-known engines and treat them as valid DB URIs even in the absence of a <code>db:</code> prefix. I've added notes to the <a href="https://github.com/theory/uri-db">documentation</a> to that effect.

frio• 13 years ago

Could Heroku be used for some guidance on this topic? They provide database URLs[1], and have built stuff like dj-database-url[2] to implement them.

[1] https://devcenter.heroku.com/articles/heroku-postgresql [2]: https://github.com/kennethreitz/dj-database-url

justtheory7• 13 years ago

That was one of the precedents I looked at, but I should definitely touch base with Heroku to see if they have any suggestions, too.

advisedwang• 13 years ago

Relevant xkcd: http://xkcd.com/927/

ibotty2• 13 years ago

the difference is that there is _no_ standard so far...

memracom2• 13 years ago

This is something that really should be done under the auspices of the IETF. Folks interested in this should ask the IETF to set up a WG and they should include a generic network database protocol (or protocols) as one of the goals. Some people will just want to work out the URI issue but others will be interested in seeing through the larger issues.

zimbatm2• 13 years ago

There is probably more than these options that you want to serialize into the URI. For example the MySQL client can be configured with an encoding charset, or maybe you want to specific the size of the connection pool ?

ibotty2• 13 years ago

isn't that something that should go in the 'query', e.g.:

    db:mysql://user@host/db?encoding_charset=utf8

zimbatm2• 13 years ago

I'm sure it will technically work but is it still really an URI ? URI is meant for resource identification. Here connection details are crammed into the 'query' to access a DB.

It might be better to come up with another "one-line string" format that's better adapted for DB connection, is regular and more easily parsed.

Toward A Database URI Standard

Related Stories