When processing auto-connection, plug and slot rules from snap-declarations are used as constraints/predicates to find candidate plug/slot pairs.
While for slots we allow both for auto-connection and in general any number of connected plugs, for plugs we auto-connect only if there is a single/unique candidate slot for a given plug.
But we have use cases (with themes for example and the content interface) where we would like and it makes sense to allow a plug to connect to all relevant available slots on the system.
We would like a way to request for this different behavior through plug and slot rules. It should be noted that this a different kind of constraint on the whole set of candidates, not on each pair.
We need a way to request this from either the plug side or slot side of rules.
In general for a given snap and interface we might not want to switch to the different behavior for all the slots or plugs but only some.
First let’s remember in the rule subtree in a
allow-* stanza, all lists represent ORed constraints and maps are ANDed constraints. The top level is a possibly degenerate OR. When we check the constraints we short-circuit at the first succeeding map of constraints. So for a succeeding
allow-* constraint there is exactly one relevant
plug-snap-type/.../plug-attributes/slot-attributes/... constraints map.
For constraints maps under
*-installation ) we will introduce optional
plugs-per-slot keys, at the moment the following values would be accepted syntactically:
- an integer
*to mean any number of
The keys are not additional constraints on pairs, but if the overall
allow-[auto-]connection succeeds because of the constraint the keys are in, then they are constraints on the cardinality of the candidate sets as a whole.
Every candidate plug and slot pair will have associated values for these keys, with the following defaults:
* means any (number of), and
1 means zero to one.
For now syntactically valid values different from the defaults will be ignored, except for:
For a given plug when we look at all the candidate pairs it is in, if they have different
slots-per-plug values we have ambiguity and no auto-connection will occur.
slots-per-plug values are
1 we get the current behaviour, we auto-connect only if there is exactly one candidate pair in the set.
slots-per-plug values are
*, all the candidate pairs will be auto-connected.
In the future we might support more non-default values and possibly range values for these candidate set constraints, but we do not have yet clear use cases for those.
If we turn the camera interface to be purely hotplug based, we can then still grant a snap access to all cameras by doing:
Allow greedy content plugs for given slots: