Toward A Database URI Standard(theory.so)
theory.so
Toward A Database URI Standard
http://theory.so/rfc/2013/11/26/toward-a-database-uri-standard/
7 comments
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?
Would it not be
file:///path
as per RFC 1738?
file:///path
as per RFC 1738?
I guess that could work.
file:///path?foreign_keys=ON;journal_mode=WALI would be okay with having just one one, though in principal I don't see much difference.
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.
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.
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>.
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.
Publish an RfC.
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.
I'd be much more comfortable following an RFC than a blog post.
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.
Publishing an RFC is not that straightforward because of the formatting requirements. In any case, whether you go on a blog or publish a draft RFC, you WILL get shot down a lot. Part of the territory.
If I were you I would contact some people who have done RFCs before and ask their advice. Contact the Applications Area directors at the IETF and ask for advice. Barry Leiba <[email protected]> Pete Resnick <[email protected]> If they think that this work belongs in a new WG then they can help you get it set up.
If I were you I would contact some people who have done RFCs before and ask their advice. Contact the Applications Area directors at the IETF and ask for advice. Barry Leiba <[email protected]> Pete Resnick <[email protected]> If they think that this work belongs in a new WG then they can help you get it set up.
Thank you, I will do that!
So what you're saying is, this blog post is a... puts shades on request for comments?
YEEEEEEEEEAAAAAAAHHHHHHH!
(please don't hurt me)
YEEEEEEEEEAAAAAAAHHHHHHH!
(please don't hurt me)
Sounds great! Let me know if you need any help with that process.
Will do. Is this thread a good place to get back to you guys if/when a WG is set up? Would likely be after the US holidays…
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
[1]: https://devcenter.heroku.com/articles/heroku-postgresql [2]: https://github.com/kennethreitz/dj-database-url
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.
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.
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 ?
isn't that something that should go in the 'query', e.g.:
db:mysql://user@host/db?encoding_charset=utf8I'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.
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.
What might such a thing look like?
Part of the reason I like my proposal is because it's just a generic server URI, so deeply familiar to nearly all developers. And for that format, it's the GET query string that allows for additional parameters.
Part of the reason I like my proposal is because it's just a generic server URI, so deeply familiar to nearly all developers. And for that format, it's the GET query string that allows for additional parameters.
Relevant xkcd: http://xkcd.com/927/
the difference is that there is _no_ standard so far...
edit: wow rfc1738 is like two rfcs ago, we're up to rfc3986 now. rock!