Thanks for answering the questions. I didn't found any JIRA for enhancing the prefix in link routing, so I entered DISPATCH-159 <https://issues.apache.org/jira/browse/DISPATCH-159>.
Regards Jakub On Tue, Aug 25, 2015 at 4:58 AM, Ted Ross <[email protected]> wrote: > > > On 08/19/2015 11:15 AM, Jakub Scholz wrote: > >> I spent some time playing with Qpid Dispatch (0.4) in combination with >> Qpid >> C++ broker. I was impressed about what it does already. Big +1 to everyone >> involved. >> >> I still run into some issues / limitations / questions ... maybe someone >> can help with them ... >> >> 1) Is there some technical reason why the linkRoutePattern isn't allowed >> to >> contain any periods (well, apart the one at the end) and why it has to end >> with a period? In my use case, almost every address name contains several >> periods in it and in many cases the important part in the address is only >> after the last period. So it would be very useful to be able to use >> multiple periods in the linkRoutePattern prefix and to be not required to >> end the prefix with a period. >> > > There is no technical reason for this limitation. It was done for > expediency to prove the link-routing concept. This should be expanded to > match any pattern. > > >> 2) The Listener allows to configure the certDB and trustedCert parameters. >> I thought that one is for CAs and one is for self signed certificates. But >> it doesn't seem to be that easy. Can someone explain how are they supposed >> to work? >> > > This functionality comes straight from Proton. It is my understanding > that certDB can be for CAs or self-signed certs. The trustedCert parameter > can be used to constrain the set of certificates in the DB that are > considered trusted for this listener. > > Perhaps someone else can provide some more clarity. > > >> 3) In the configuration file, what is the relation between "router", >> "container", "listener" and "connector"? Is there some kind of hierarchy >> between them? It almost seems that "router" and "container" are entities >> which always apply to the whole Dispatch process and can be used only >> once. >> Is that correct? >> > > That is correct. In fact, we plan to combine the configuration in > "container" and "router" into a single section (probably router) to reduce > the confusion. > > >> 4) The DISPATCH-58 issue seems to be quite annoying - are there any plans >> to fix it? >> > > Yes, I'm planning a refactor of the ingress links that will improve the > ability to use flow control across the network. This will likely improve > the DISPATCH-58 issue. > > >> Thanks & Regards >> JAkub >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
