Improvements in the content interface

snapd
1

I had a discussion with @niemeyer yesterday about theme support. Here are the relevant points I remember:

  1. As mentioned above, the interface system doesn’t preclude having multiple slots attached to a plug simultaneously. So there is no need to invent a new concept to support this. This is not currently in use though, so may be buggy.

  2. Potential implementation: each theme snap provides a content interface slot, and each app has a matching content interface plug: all theme snaps connect to all app snaps.

  3. Current yaml schema for content interface supports a slot providing multiple directories, but they all end up getting mounted on top of each other. But one slot providing multiple directories is quite similar to multiple slots providing one or more directories each: perhaps there is one solution to both problems?

  4. @niemeyer suggested a slight extension to current syntax:

    slots:
  foo:
    interface: content
    content: content-id
    source:
      read:
        - $SNAP/folder1
        - $SNAP/folder2
      write:
        - ...

plugs:
  bar:
    interface: content
    content: content-id
    target: $SNAP/dest

    Rather than mounting the content directly at $SNAP/dest in the plug-side snap, the provided content folders would be exposed as subdirectories. The subdirectory names would match the basenames of the source folders (i.e. at $SNAP/dest/folder1 and $SNAP/dest/folder2 in the above example). If two folders have the same base name, a new name will be chosen (e.g. if there are two folders named foo, the second might be renamed foo.2). For the “multiple slots” case, this would require some coordination between the individual interface connections.

    This could be implemented on top of the future layouts feature: mount a tmpfs on top of the target mount point, create subdirectories under it for each shared directory, and perform the additional mounts.

2 Likes
2

@jamesh @zyga-snapd @till.kamppeter I’ve split that out of the GTK theme topic so we can discuss and track the work without polluting the original topic which issues not related to themes.

1 Like
3

As another detail we discussed around these changes, the fact both sides of the interface will become symmetrical, with source on one end and target on the other, also means we can conveniently have both sides (slot and plug) providing or consuming content. It would be nice to get that working as a follow up step on the basics described above.

4

EDIT: replaced with current status

I’ve implemented most of this in:

I need to add one more patch to make plugs and slots symmetric but I need to ponder about that still. I plan to write some spread tests to ensure this really works but those will only be possible once 4008 and yet-unproposed overlayfs PR is merged.

1 Like
5

All of the PRs have landed and the feature is enabled and working in 2.31. I will be working on documenting it by integrating improvements into the content interface documentation thread on the forum.

3 Likes