I think we need to focus the URL syntax discussion on a specific
proposal with concrete syntax to be implemented.
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]
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.]
* 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.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
