pub enum DegradeRule {
StructuredContentToText,
DropAnnotations,
AudioToTextPlaceholder,
DropAudio,
DropImage,
DropResourceLink,
DropResource,
}Expand description
One thing lowering may do to make a value expressible.
Variants§
StructuredContentToText
Serialise structuredContent into a text content block.
Added 2025-06-18; the specification names this as the recommended
fallback. Lossless: the bytes are unchanged, only the carrier differs.
DropAnnotations
Drop annotations a revision does not define.
Loss::Flagged. Annotations arrived in 2025-03-26 and a
2024-11-05 peer simply ignores them, so nothing that peer could have
acted on is lost — but a bridge that drops them without saying so is
lying about what happened.
AudioToTextPlaceholder
Replace an audio block with a text placeholder naming it.
Loss::Destructive, and there is no lossless alternative: there is no
textual stand-in for audio. For this reason it is the one rule the
specification does not sanction, and a caller must name it.
DropAudio
Drop an audio block.
DropImage
Drop an image block.
DropResourceLink
Drop a resource link, 2025-06-18 and later.
DropResource
Drop an embedded resource.
Implementations§
Source§impl DegradeRule
impl DegradeRule
Sourcepub const ALL: &'static [Self]
pub const ALL: &'static [Self]
Every rule a DegradePolicy can select
to satisfy a missing feature, in a stable order so a policy set or a
report reads the same way twice.
Every rule here names a feature, which is the invariant that keeps the
list honest: a rule in this list is reachable by rule_for, and a rule
that is not in it is not reachable by a policy at all.
The three that are not listed — AudioToTextPlaceholder,
DropImage and DropResource — are opt-in
reductions rather than
fallbacks. The placeholder because the specification does not sanction it
and dropping the block is the only policy-selectable response to audio;
the other two because images and embedded resources are expressible at
every revision, so no revision’s absence ever requires dropping them.
Listing any of them would let rule_for hand back something a caller
never asked for, or that could never apply.
Sourcepub const fn feature(self) -> Option<Feature>
pub const fn feature(self) -> Option<Feature>
The feature whose absence this rule exists to work around.
None for a rule that is not a fallback — a reduction a caller opts
into for its own reasons, not something a revision forces. Images and
embedded resources have been expressible since 2024-11-05 and
annotations are simply ignored by older peers, so there is no revision
whose absence ever makes dropping them necessary. Reporting a feature
for them would be a lie about why the rule exists, and would make
rule_for offer them as answers to a question they
cannot answer.
Sourcepub const fn loss(self) -> Loss
pub const fn loss(self) -> Loss
How much this rule gives up.
Only DropAnnotations is Loss::Flagged. Every rule that
removes a content block is Loss::Destructive, because a block the tool
produced is the tool’s answer: dropping it does not degrade the message,
it makes it say something the tool did not. Calling that “flagged” would
let a bridge promise “lossless or flagged” and quietly remove content.
Sourcepub fn is_fallback_for(self, feature: Feature) -> bool
pub fn is_fallback_for(self, feature: Feature) -> bool
Whether this rule is the one that makes a value needing feature
expressible again.
Not const: Feature’s PartialEq is not const-callable, the same
trade T05 made on defined_in.