Expressing branching configurations with configurl

[fortuna]

Configurl makes it easy to compose components in a linear chain. Some components need multiple independently configured inputs:

• Happy Eyeballs needs a DNS resolver and a stream dialer for destination connections.
• The Outline client needs a stream dialer for TCP and a packet listener for UDP.

Embedding config URLs inside other URLs becomes difficult to read because of escaping. Could we express these branches using markers within the existing pipe-separated format?

For example, assuming a doq resolver component:

socks5://[CREDS]@[HOST]:[PORT]|he-base|split:20|he-dialer|quicprelude|doq:name=cloudflare-dns.com|he

The final he component would create a Happy Eyeballs stream dialer with these inputs:

Resolver:

socks5://[CREDS]@[HOST]:[PORT]|quicprelude|doq:name=cloudflare-dns.com

Dialer:

socks5://[CREDS]@[HOST]:[PORT]|split:20

The common prefix supplies the base for both branches. The markers identify where that prefix ends and where each branch ends.

One possible implementation is for the he parser to inspect the configuration on its left, construct the two branch configurations, and build the resolver and dialer through the registry. This would preserve the existing URL-chain syntax without another layer of URL escaping.

With the generic registry proposed in #647, a component library could implement this independently, without changing the registry API or requiring SDK approval.

Naming and grouping

The marker names are open for discussion. Some possibilities are:

BASE|he-end|DIALER|he-dialer|RESOLVER|he-resolver|he

This explicitly labels both inputs and keeps he as the component that combines them.

BASE|he-end|DIALER|he-dialer|RESOLVER|he-resolver

This removes the final he, but would give he-resolver responsibility for completing the group and producing the result.

BASE|he-end|DIALER|he-dialer|RESOLVER|he

This is shorter: the final he implicitly ends the resolver branch and combines the inputs.

There is also a naming-direction question. Configurations are written left to right, but construction starts with the rightmost component and follows its dependencies to the left. he-end could mean “stop collecting inputs here,” while he-base describes the common prefix’s role. Which is easier to understand?

A generic map

Instead of component-specific markers, we could collect named branches into a map:

BASE|map-end|RESOLVER|map-entry:key=resolver|DIALER|map-entry:key=dialer|map-start|he

Each entry would use the same common prefix, producing:

resolver → BASE|RESOLVER
dialer   → BASE|DIALER

The he component would consume those entries. The same mechanism could collect tcp and udp inputs for an Outline-client component.

One possibility is for the map to hold configurations rather than constructed objects. Then he would request resolver as a dns.Resolver and dialer as a transport.StreamDialer. The map mechanism would not need to know those types in advance.

This raises several questions:

• Are component-specific markers easier to explain than a generic map?
• Should start and end follow reading order or construction order?
• How should nested groups match their boundaries?
• Should empty branches use the common prefix directly?
• Does the common prefix share only configuration, or also constructed instances and caches?
• For maps, how should duplicate or missing keys be handled?

This is an idea to explore separately from the current registry changes.