Missing interface: content sharing in the other direction

[Kyle Fazzari]

The content interface currently solves use-cases like an SDK snap, where multiple consumers use the contents of the provider. However, it doesn't solve the use-cases of plugin systems, where multiple providers (e.g. plugins, add-ons) want to get into the execution context of a single consumer (the main process). This would be useful for anything that exposes a plugin/add-on system: gedit, geany, nextcloud, etc.

[Zygmunt Krynicki (zyga)]

I think the content interface does solve that. What is harder is to figure out who can connect to who. I think the assertion system should control this, then the content system can do the rest.

[Gustavo Niemeyer (niemeyer)]

Both approaches (existing interface or new interface) are technically feasible and relatively simple to support from where we are today.

Instead of just going for reuse, we should take a step back and think through the whole experience of someone trying to implement a plugin mechanism, and take the decision based on that.

For example:

- How would the content be made available inside both snaps?

- Which commands would be used to establish the relation? Are these reasonable or awkward?

- Which events will either snap need to be notified about for things to work?

[Kyle Fazzari (kyrofa)]

I'm not sure I completely understand the questions, but I'll take a crack at them. Please ask for clarification if needed.

> - How would the content be made available inside both snaps?

At least for the systems with which I'm familiar, there's some sort of plugin directory in the main app. In that case, I'm not sure any content would need to be made available inside the plugin snap. The plugin itself would need to be mounted into the main app's "plugin space."

> - Which commands would be used to establish the relation? Are these reasonable or awkward?

Again, in the case of of the systems with which I'm familiar, if the plugins are available in the plugin directory, the main app provides a way to enable them. Gedit has a menu where you can view available plugins and enable them, as does Nextcloud.

> - Which events will either snap need to be notified about for things to work?

If Nextcloud were made aware of a new plugin being added, it could automatically enable it. I assume other systems work similarly. This could be done via an interface hook. I think it would probably be more important to notify the main app when a plugin was removed, since once it's added it'll probably continue looking for it. Still an interface hook, I imagine.

[Simon Fels (morphis)]

I have a similar use case where a application can be extended with plugins for further functionality. In this case they don't need to be in a particular path but the main snap needs to take a single file from the plugin snap and process it further. It also needs to know when the plugin snap was removed or upgraded so it can either remove or reload the plugin in the application.

Upgrade or removal detection can be either done via interface hooks or via filesystem events the main application listens for. What I am missing more is the ability in the main snap to choose where the plugin snaps get mounted to via the content interface. Right now I have to define a static path in my snap.yaml. It would be an idea to delegate this decision to an interface hook so that the main snap can decide where inside SNAP_DATA/SNAP_COMMON the plugin snap content gets mounted to so it can create a directory per plugin snap or similar.

[Roberto Mier Escandon (rmescandon)]

I've hit this issue in Nextcloud when trying to integrate it with nextant application and Solr server to enable documents search. Having that in other snap would need some kind of communication with nextcloud one which is not now possible until having this fixed.

[Zygmunt Krynicki (zyga)]

Hey

Can you tell me more about what would be required for nextant and
nextcloud to work together? I'm working on polishing (pun intended)
the content sharing interface. Apart from the things I know and I'm
working on I'm on the look out for things that are broken or not
documented or insufficient for what people want to do.

On Tue, Jan 24, 2017 at 11:27 AM, Roberto Mier Escandón 
<email address hidden> wrote:
> I've hit this issue in Nextcloud when trying to integrate it with
> nextant application and Solr server to enable documents search. Having
> that in other snap would need some kind of communication with nextcloud
> one which is not now possible until having this fixed.
>
> --
> You received this bug notification because you are a member of Snappy
> Developers, which is subscribed to Snappy.
> Matching subscriptions: xxx-bugs-on-snapd
> https://bugs.launchpad.net/bugs/1655125
>
> Title:
> Missing interface: content sharing in the other direction
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy/+bug/1655125/+subscriptions

[Roberto Mier Escandon (rmescandon)]

Nextcloud has several default internal applications included in the product when it is deployed/installed. It also accepts other applications created by any user to perform whatever is needed. Nextcloud snap, when installed, sets a path into its common folder for those extra apps. It is supposed to have every extra app in a separated snap from the nextcloud one. So, the requirement should be having "myapp" snap be able to deploy the app in the nextcloud snap common folder somehow, so that nextcloud can make use of it.
In the specific case of search support, Solr is the server where the documents index is held and nextant is the application to be deployed in nextcloud common folder path. (or communicated with nextcloud using content interface)

[Robert Ancell (robert-ancell)]

This is what I need to do the LightDM snap correctly, for example you might have two greeter provider snaps (Unity greeter, GTK+ greeter).

The LightDM snap would provide a greeter slot and connecting multiple greeter plugs would allow it to discover and make use of these.

[Didier Roche-Tolomelli (didrocks)]

From my post on the snapcraft ML:
So, I'm in the situation where one snap would need to get configuration
and access to some files from other snaps. It's really similar to our
plugin story: even if in that case, we are talking about optional
configuration and files from one or multiple snaps shared with a single
one collecting them all.

I can see 2 options in the snapd philosophy:

- Content sharing. Sounds like it matches exactly the purpose of it.
However, even disregarding the manual connection that will be needed, we
are stuck on the fact that it's limited to one connection for a given
slot. If I want to share configuration and files from 3 snaps to the
master one, I can't do 3 times:
$ snap connect snap1:config my-master-snap:config
$ snap connect snap2:config my-master-snap:config
$ snap connect snap2:config my-master-snap:config

One way would be to create different slot names:
$ snap connect snap1:config my-master-snap:config1
$ snap connect snap2:config my-master-snap:config2
$ snap connect snap2:config my-master-snap:config3

But this doesn't help on the ease of use (the notice is then for people
"find the first available slot"… Not really user-friendly) nor in the
scalability (fixed number of slots…)

[Zygmunt Krynicki (zyga)]

I'm marking this as triaged just ack the existence and validity. This needs more research and discussion though.

[Kyle Fazzari (kyrofa)]

When can we have this conversation?

[Till Kamppeter (till-kamppeter)]

Me too: I am snapping CUPS so that printer drivers can be provided as snaps (= distro-independent packages) which connect to CUPS as a plugin. So I need exactly the feature requested here.

[Till Kamppeter (till-kamppeter)]

See also this thread on the Snapcraft forum:

https://forum.snapcraft.io/t/snapping-cups-printing-stack-printer-drivers-as-plugins/1503

[Gustavo Niemeyer (niemeyer)]

I believe the solution for these needs are the same of those being discussed to support GTK themes via the content interface. The changes are being discussed here:

https://forum.snapcraft.io/t/improvements-in-the-content-interface/2387

Let's please move further discussion on this topic there.

[Zygmunt Krynicki (zyga)]

We are not currently working on implementing this new feature.