Daemon: dbus examples

[Jamie Strandboge]

On Tue, 2016-12-13 at 09:31 +1000, Michi Henning wrote:
> > 
> > In snapd 2.20 we are working to have the 'dbus' generic interface in
> > place[2].
> > With it you can specify the bus name (session or system), the well-known
> > name to
> > bind to and then use interface connections to connect your client to your
> > service.
> Thanks for that Jamie!
> 
> I take I’ll be able to specify the dbus name dynamically? We need this for
> storage service, where the client app doesn’t know a-priori which exact
> service it will be talking to. Instead, that’s determined by the user, who
> selects which cloud service they want to use (say, for backup). The providers
> for the different cloud services each use a different dbus name, so the actual
> dbus name an application needs to use isn’t know until runtime.
> 
As implemented, the slot implementation picks the well-known name it is known by
and then 'snap connect' is used to connect plugging clients to the services.
Each provider would claim a well-known name and each client *could* plug and
snap connect any or all of them. Then at runtime the client could choose
whichever they want to use.

Based on your comments though, it sounds like perhaps you would want to have the
storage service plug all the known cloud providers, then expose it via its own
interface and have clients plug the storage service. Clients talk to the storage
service and the storage service mediates communicates with the cloud providers.
In this manner, the storage service only has to ever be updated to plug new
cloud providers (something it would need to do any way) and the clients never
have to be updated.

Feel free to schedule a meeting sometime with me, Tyler/Emily and Thomas Voss if
desired if you want input on the design or a design review.

> > 
> > In a future version of snapd, service activation will be supported[3] (eg,
> > for
> > session services) as well as running daemons on the session bus[4]. AIUI the
> > Ubuntu Personal folks are working on this and they have a design and the
> > implementation should start soon. Thanks!
> So, I take that we’ll be able to use this for things such as thumbnailer and
> mediascanner? I’m asking because, if so, there is no point in me trying to add
> service-specific interfaces for these to snapd.
> 

Maybe. As I see it, there are two main considerations here:

1. the entire DBus API is granted (currently) when using this particular
interface. If these service's entire DBus APIs are safe (ie, they don't violate
application isolation or grant elevated permissions), then this interface could
be appropriate for them.

2. are these services otherwise interesting enough to have their own interface
on their own?

Gustavo may have other considerations or thoughts on the matter. Do note that
the interface as implemented today (ie, without session services or activation)
is meant to allow leaf applications (eg, from GNOME or KDE) to work and talk to
each other and integrate within the user's session. We'll work with Thomas on
the activation and session service bits and then after that see how people want
to use the interface and iterate.

> Do you have a rough ETA for this? (No, I’m not going to hold you to it :-
> )  Just trying to get a feel for where things are at.)
> 
I'm told these are behind the trusty work, that the trusty work is nearing
completion and that this dbus work will start after that. I suggest asking the
Ubuntu Personal folks directly for when this might start/be completed.

-- 
Jamie Strandboge             | http://www.canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20161213/be8779c7/attachment.sig>