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" <[email protected]>
To: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
