vlc mpris

[James Henstridge]

On 14 February 2017 at 08:01, Jamie Strandboge <jamie at canonical.com> wrote:
> On Mon, 2017-02-13 at 15:30 +0800, James Henstridge wrote:
>> On 13 February 2017 at 15:02, Vasilisc <vasilisc777 at gmail.com> wrote:
>> >
>> > How to allow vlc - "org.mpris.MediaPlayer2.vlc.instance*" ???
>> >
>> > [0xd5f358] dbus interface error: Error requesting service name
>> > org.mpris.MediaPlayer2.vlc.instance3045: Connection ":1.69" is not allowed
>> > to own the service "org.mpris.MediaPlayer2.vlc.instance3045" due to AppArmor
>> > policy
>> >
>> > ------------------------------
>> > I don't see interfaces dbus|mpris
>> >
>> > # LANG=C apt policy snapd
>> > snapd:
>> >   Installed: 2.21
>> >   Candidate: 2.21
>> >   Version table:
>> >  *** 2.21 500
>> >         500 http://fi.archive.ubuntu.com/ubuntu xenial-updates/main amd64
>> > Packages
>> >         100 /var/lib/dpkg/status
>> >      2.0.2 500
>> >         500 http://fi.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
>> >
>> > # snap interfaces | grep -E "(dbus|mpris)"
>> > #
>> You should be able to do this by adding a slot to your snap using the
>> "mpris" interface.  Something like this:
>>
>> slots:
>>   mpris:
>>     interface: mpris
>>     name: vlc
>>
>> Then make sure the app inside your snap uses this slot.
>>
>> This interface looks like it will work okay for the mpris provider,
>> and okay for unconfined mpris clients on classic systems.
>
> Correct
>
>> It's not
>> clear how you'd write a confined client that could act as a remote for
>> all installed players without defining many duplicate plugs.  If
>> you're only interested in use on classic systems though, this should
>> be good enough though.
>
> It works kind of like the dbus interface but is a bit simpler. It is documented
> here:
> https://github.com/snapcore/snapd/wiki/Interfaces#mpris
>
>
> Specifically if the providing snap has:
>
> name: vlc
> apps:
>   vlc:
>     slots: [mpris]
>
> then vlc is allowed to bind to the DBus well-known name
> 'org.mpris.MediaPlayer2.vlc'. Plugging snaps do:
>
> name: foo-vlc-controller
> apps:
>   foo-vlc-controller:
>     plugs: [ mpris ]
>
> then can be connected with:
> $ sudo snap connect foo-vlc-controller:mpris vlc:mpris
>
>
> The interface has some flexibility for when you want to use something different
> than the snap's name in the DBus well-known name. Eg, if the providing snap has:
>
> name: forked-vlc
> slots:
>   mpris:
>     interface: mpris # this line not needed since iface name == slot ref
>     name: vlc
>
> then forked-vlc is allowed to bind to the DBus well-known name
> 'org.mpris.MediaPlayer2.vlc'. Plugging snaps do:
>
> name: foo-vlc-controller
> apps:
>   foo-vlc-controller:
>     plugs: [ mpris ]
>
> Then on install they can be connected with:
> $ sudo snap connect foo-vlc-controller:mpris forked-vlc:mpris
>
>
> Notice that foo-vlc-controller doesn't care about what is on the other end (vlc, vs forked-vlc vs rhythmbox vs whatever) and it can be connected to multiple slot implementations. This is the beauty of interfaces and how they can be thought of as 'contracts' between slots and plugs.

I can see how that works if I want to act as an mpris remote for one
player.  But what happens when we install a second player app and want
to be able to control it as well?  As I understand it, a plug can only
connect to a single slot, so I'd need to define extra plugs:

  plugs:
    mpris1:
      interface: mpris
    mpris2:
      interface: mpris
    ...

If I wanted to be able to act as a control for any running player (as
indicator-sound does, for instance), then I'd have to hope I defined
enough plugs.  And that ignores the headaches of connecting everything
up after installation.

We're facing a similar problem with storage-framework too, where there
can be multiple clients and multiple providers.  We'll probably solve
it there by adding an intermediary between clients and providers
(which hasn't yet been started), but it did stand out as another case
of many-to-many communication that doesn't neatly fit into snapd's
interface model.

James.