You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It was raised in #27 (comment), but the way to add a new condition / source type may not be considered well yet.
During gradual support of a condition or a source, or when a new source or a new condition is implemented, there can be a situation that some of conditions / sources are supported and others are not. What is the expected way to handle this?
As written in #27 (comment), there might be 4 options:
Option 1. raise if the condition is unknown. The web author should write the rule that works for both. If we choose this route, addRoutes must only ignore the rules raised and add anything else.
e.g. addRoutes(ruleA) => success, addRoutes(ruleB) => raise, addRoutes(ruleC) => success, the actual rule will be ruleA + ruleC.
Option 2. ignores an unknown condition or an unknown source, but evaluate as if it the condition does not exist.
e.g. {condition: {unknown: foo, urlPattern: "/"}, source: "network"}, it will be recorded like {condition: {urlPattern: "/", source: "network"}.
e.g. {condition: {urlPattern: "/*"}, source: "unknown"} then raise because empty source is not allowed?
Option 3. ignores the rule with an unknown condition or an unknown source.
e.g. [{condition: {urlPattern: "/"}, source: "network"}, {condition: {unknown: rule}, source: "network"}, {condition: {urlPattern: "/"}, source: "unknown"} then only [{condition: {ur](condition: {urlPattern: "/*"}, source: "network"}) will be added.
Option 4. provides the way to let web developers to know supported conditions and sources. Web developers should check the supported conditions before using it.
e.g. console.log(event.supportedConditions) then prints {"urlPattern", "requestMode", ...}
I prefer Option 1 or Option 4, but what do you think?
The text was updated successfully, but these errors were encountered:
I feel I misunderstand the point. Since a dictionary is used here, unknown fields in a dictionary might just be ignored instead of raising like a wrong type is given.
It was raised in #27 (comment), but the way to add a new condition / source type may not be considered well yet.
During gradual support of a condition or a source, or when a new source or a new condition is implemented, there can be a situation that some of conditions / sources are supported and others are not. What is the expected way to handle this?
As written in #27 (comment), there might be 4 options:
Option 1. raise if the condition is unknown. The web author should write the rule that works for both. If we choose this route, addRoutes must only ignore the rules raised and add anything else.
e.g. addRoutes(ruleA) => success, addRoutes(ruleB) => raise, addRoutes(ruleC) => success, the actual rule will be ruleA + ruleC.
Option 2. ignores an unknown condition or an unknown source, but evaluate as if it the condition does not exist.
e.g. {condition: {unknown: foo, urlPattern: "/"}, source: "network"}, it will be recorded like {condition: {urlPattern: "/", source: "network"}.
e.g. {condition: {urlPattern: "/*"}, source: "unknown"} then raise because empty source is not allowed?
Option 3. ignores the rule with an unknown condition or an unknown source.
e.g. [{condition: {urlPattern: "/"}, source: "network"}, {condition: {unknown: rule}, source: "network"}, {condition: {urlPattern: "/"}, source: "unknown"} then only [{condition: {ur](condition: {urlPattern: "/*"}, source: "network"}) will be added.
Option 4. provides the way to let web developers to know supported conditions and sources. Web developers should check the supported conditions before using it.
e.g. console.log(event.supportedConditions) then prints {"urlPattern", "requestMode", ...}
I prefer Option 1 or Option 4, but what do you think?
The text was updated successfully, but these errors were encountered: