You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Ted Ross <tr...@redhat.com> on 2016/11/16 16:54:25 UTC
Dispatch Router Iterator changes
The iterator module in Dispatch Router is in need of some clean-up and
re-factoring. It has undergone several rounds of evolutionary extension
and is resisting further extension (for support of multi-tenancy).
I propose the following change to the iterator module as a starting point.
Remove the false hierarchy of "field" iterators and "address"
iterators. In the process, shorten the names of all the methods to
be just "qd_iterator_<method>"
Opinions welcome,
-Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Dispatch Router Iterator changes
Posted by Ted Ross <tr...@redhat.com>.
Thanks Ken,
This module has already gone beyond generic fields and addresses. It
now also normalizes router IDs (passed in message annotations). I'd
like to think of it in more general terms.
The iterator has three main functions in the context of Dispatch Router:
- It abstracts away the fact that protocol fields may not appear in
contiguous memory blocks. Protocol data received from the wire is
stored in chained buffers.
- It provides normalized views of fields for use as keys in hash/map
data structures. This is used for AMQP addresses as well as router
IDs.
- It provides annotation of the normalized views as a way to provide
some of the more advanced routing features in Dispatch Router.
Currently the annotation is limited to address-type and mobile-
address phases (for waypoint routing). It will shortly also support
address name-spaces for multi-tenancy.
I think the modern intent of this module can be more clearly expressed
by simplifying the API and removing the field/address distinction.
-Ted
On 11/16/2016 12:26 PM, Ken Giusti wrote:
> Hi Ted,
>
> I originally split the iterator functionality into to types - a generic field iterator and an address-field specific interator - simply to provide some clarity and enforce proper usage (e.g. address iterators for address fields, generic interators for the rest).
>
> The original iterator type had extra logic for dealing with address type fields - state such as prefix, view type, and parsing fields with '/' having special significance. This required the user of the iterator to be careful to use the proper methods based on the semantics of the field being iterated over. But there was no way to enforce correct usage based on the type of field being parsed. One could easily pass say a username field to a function that expected to parse an address without any indication of the error.
>
> Again, just my opinion. I haven't worked on the dispatch codebase for awhile so this view may be out of date.
>
> If combining the two types back into a generic type can help optimize the performance of iterators then that's more important.
>
> Is it possible to provide compile-time checking to prevent using address field logic with non-address field instances (and maybe vice versa)?
>
> -K
>
>
> ----- Original Message -----
>> From: "Ted Ross" <tr...@redhat.com>
>> To: dev@qpid.apache.org
>> Sent: Wednesday, November 16, 2016 11:54:25 AM
>> Subject: Dispatch Router Iterator changes
>>
>> The iterator module in Dispatch Router is in need of some clean-up and
>> re-factoring. It has undergone several rounds of evolutionary extension
>> and is resisting further extension (for support of multi-tenancy).
>>
>> I propose the following change to the iterator module as a starting point.
>>
>> Remove the false hierarchy of "field" iterators and "address"
>> iterators. In the process, shorten the names of all the methods to
>> be just "qd_iterator_<method>"
>>
>> Opinions welcome,
>>
>> -Ted
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Dispatch Router Iterator changes
Posted by Ken Giusti <kg...@redhat.com>.
Hi Ted,
I originally split the iterator functionality into to types - a generic field iterator and an address-field specific interator - simply to provide some clarity and enforce proper usage (e.g. address iterators for address fields, generic interators for the rest).
The original iterator type had extra logic for dealing with address type fields - state such as prefix, view type, and parsing fields with '/' having special significance. This required the user of the iterator to be careful to use the proper methods based on the semantics of the field being iterated over. But there was no way to enforce correct usage based on the type of field being parsed. One could easily pass say a username field to a function that expected to parse an address without any indication of the error.
Again, just my opinion. I haven't worked on the dispatch codebase for awhile so this view may be out of date.
If combining the two types back into a generic type can help optimize the performance of iterators then that's more important.
Is it possible to provide compile-time checking to prevent using address field logic with non-address field instances (and maybe vice versa)?
-K
----- Original Message -----
> From: "Ted Ross" <tr...@redhat.com>
> To: dev@qpid.apache.org
> Sent: Wednesday, November 16, 2016 11:54:25 AM
> Subject: Dispatch Router Iterator changes
>
> The iterator module in Dispatch Router is in need of some clean-up and
> re-factoring. It has undergone several rounds of evolutionary extension
> and is resisting further extension (for support of multi-tenancy).
>
> I propose the following change to the iterator module as a starting point.
>
> Remove the false hierarchy of "field" iterators and "address"
> iterators. In the process, shorten the names of all the methods to
> be just "qd_iterator_<method>"
>
> Opinions welcome,
>
> -Ted
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org