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!
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 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.
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 <barryleiba@computer.org>
Pete Resnick <presnick@qti.qualcomm.com>
If they think that this work belongs in a new WG then they can help you get it set up.
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 ?
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.
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.
edit: wow rfc1738 is like two rfcs ago, we're up to rfc3986 now. rock!