{imp9:0} Legend: for this rationale, the examples will use buses, networks and hubs, as shown below:
|
Each object is annotated by its type and key=value pairs of a few, selected attributes.
{imp9:1} The simplest channel based connection is when a network is connected to a bus using a hub:
 |
The network is hooked up onto one of the bus channels. If the chan_rewrite attribute of the hub is empty or does not modify the participants (the bus and the network), the connection is made using pure channel attributes. That is, the network has chan=G so it connects to the channel of the bus that also has attribute chan=G.
{imp9:2} If the network names a channel that does not exist in any of the buses that are connected to the hub, the network remains unconnected (the GUI should warn for this):
 |
{imp9:3} Similar things happen when two buses are connected via a hub; the connection is made channel by channel:
 |
{imp9:4} When the hub's chan_rewrite attribute is set to B2::B::G, that means any chan name in B2 is transformed, replacing regex B with string G. In practice, this means the channel that was originally B in bus B2 is now called G and connected accordingly. Because the second field uses regex, a safer description of the pattern would be: B2::^B$::G, so the chan name is modified only if it is "B", not if it "contains B". Note that the real chan name in B2 remains "B", the rewrite rule affects only the binding within the hub:
 |
{imp9:5} The same mechanism can be used to disconnect one of the channels; for example the chan_rewrite entry in the hub B2::^B$:: would replace "chan=B" to "chan=", making the channel association to empty, which will not cause a connection. This way B2's channel 'B' is left unconnected:
 |
{imp9:6} In the following example we will define two R,G,B buses B2 and B3, and a more complex, "hierarchical" bus B1 that includes two full sets of R,G,B "sub-buses", called the "left sub-bus" and the "right sub-bus".
{imp9:7} Using the conventions of hierarchy, it is possible to design a bus B1 so that it has two full copies of the R,G,B channels, one prefixed "left/", the other prefixed "right/". By convention, the user calls "left/" and "right/" sub-buses. When two "plain" R,G,B buses B2 and B3 are connected, the user shall decide which sub-bus they should connect to. For this, we are going to modify all three chan names in both B2 and B3, using the following two chan_rewrite rules at hub H1:
B2::^::left/
and this chan_rewrite at hub H2:
B3::^::right/
 |
The regex part in the above rule, "^", means: "match the beginning of the string". This effectively means we replace the beginning of the string, or in other words, insert before the original string. What we insert is "left/" in case of B2 and "right/" in case of B3.
{imp9:8} At the end of the day, this simple trick means the hubs could prefix the channel names of incoming buses locally, without affecting the bus or other connections of the bus, effectively changing where the channels of this bus would connect to within the other bus. Using this mechanism together with the bus-hierarchy-channel-naming convention, hierarchical buses can be emulated.