On Fri, Jun 22, 2012 at 12:28:00PM -0400, Andrew Stitcher wrote: > I think we need to focus the URL syntax discussion on a specific > proposal with concrete syntax to be implemented.
+1
> I think we should take this in parts, and it appears to me that we have
> somewhat muddies the waters by conflating the connection URL syntax and
> the connection string (including whatever options) together.
>
> For concreteness here is a proposal (it is the best most overlapping
> syntax with both c++ and python syntaxes that I can think of presently):
>
> I'm only covering a *single url* here and multiple urls will need to be
> combined either in a list or in options as elsewhere discussed on the
> thread.
>
> scheme ::= "amqp" | "amqps" | "amqpr"
> host ::= name | ipv4literal | "[" ipv6literal "]"
> url ::= [scheme ("://" | ":")] [user ["/" password] "@"] host [":" port]
Why not use ":" as the delimter between username and password? This
would be more consistent with standard URIs.
> There are a few things to note here:
>
> * It is relatively simple to parse except (simple here meaning no
> backtracking is required)
>
> - Allowing ":" as well as "://" in the place after the scheme adds a
> potential ambiguity to the syntax. If we didn't allow it then amqp:5672
> would unambiguously denote a url connecting to host called amqp and port
> 5672. However allowing it it would denote that or a host called 5672 and
> the default port.
>
> This might not seem like a big issue, but it limits the parser to
> accepting known schemes, which is not great. It would be better for the
> parser to be able to tell a scheme unambiguously from the syntax.
>
> So I'd actually prefer to not allow a single ":" in this place in the
> syntax except that the C++ parser and the 0-10 syntax both allow it.
>
> [I note that as far as general uri syntax is concerned only the ":" is
> strictly necessary because what follows is not hierarchical. I think
> this would be more significant if it we didn't break the uri syntax by
> not always requiring the scheme.]
See my above comment. Granted, we don't need a "/" to separate hostname
and port information from anything hierarchical, but I think using it to
delimit username and password breaks away from a standard way of
including those elements in a URI.
> * I've not included and notion of list of addresses here.
> * I'm open to indicating the transport protocol in some other way than
> changing the scheme, but I think this works - the C++ syntax uses
> another ":" for this which adds another layer of ambiguity to the syntax
> along the lines I explained above. I do think the transport should be in
> the url though as I understand it to indicate the transport level entity
> to contact to "talk"amqp to.
>
> Having got this far I believe we are left with a further discussion
> which I have no string feelings about I just summarise my understanding
> of the discussion:
>
> The connection string syntax could be:
>
> connectionstring ::= url [";" options]
>
> or
>
> single ::= url [";" options]
> connectionstring ::= single {"," single}*
>
>
> Depending on how you believe you should get your failover/reconnect
> addresses.
>
> I hope this is clear to everyone and apologies for the cod EBNF to real
> pedants.
>
> I think we need to clear this issue up completely before embarking on
> new code which might just introduce a new and subtly different syntax.
>
> When we have sorted it out we can go and change the existing parsers and
> other code to suit.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
pgpHciM7wEmsg.pgp
Description: PGP signature
