Defining the behavior of dynamic attributes (interface hooks)

Caveat: this topic is for a work-in-progress feature, part of which is implemented with

I’d like to gather feedback and discuss potential pitfalls / use cases regarding attributes of interface hooks.

Currently all interfaces implement these two methods:

  • SanitizePlug(plug)
  • SanitizeSlot(slot)

The role of these methods is to ensure all the attributes of a plug/slot from snap’s yaml file are valid and not missing - an early validation. Sanitization is performed on snap installation, without even connecting the interface.

With interface hooks we will get two new methods called when interface hooks get executed and interface is about to be connected:

  • ValidatePlug(plug, extraPlugAttributes)
  • ValidateSlot(slot, extraSlotAttributes)

The role of these methods is to validate any extra attributes set at runtime with snapctl when interface hooks are run. I think these methods should be optional, because not every interface is interested in supporting attributes set at runtime. However, if these methods are missing but hooks are present and set any extra attributes, we will not block them and they will be visible to the interface code. Also note, that with the restrictions discussed so far and implementation in the above PR, interface hooks will not be allowed to modify existing attributes coming from the snap yaml file or provided by Sanitization step - snapctl set will reject such attempts.

With all the above, the rules of where default values should be set may be a bit unclear as we will have two places where interface attributes can be added/modified. With the restriction of not allowing modifications to plug/slot attributes after Sanitize step it looks like the best place to fill in default values is in Validate* methods.
What do you think?

Last updated 1 year, 4 months ago. Help improve this document in the forum.