Improvements in the content interface
I had a discussion with @niemeyer yesterday about theme support. Here are the relevant points I remember:
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.
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.
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?
@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/destin 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/folder2in 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.
Last updated 1 year, 2 months ago. Help improve this document in the forum.