Re: New gnome-sdk images with gnome-builder app bundle

[Simon McVittie <simon mcvittie collabora co uk>]

On 16/01/15 04:10, Cosimo Cecchi wrote:
> [adding Simon, since I'm not sure he's subscribed to this list]

I am not working on Telepathy at the moment. I don't know whether I will
be in future.

>     I don't really know telepathy all that well, but how well would it be
>     amendable to some level of sandboxing? I guess with kdbus we could ship
>     the client libraries and they would just error out completely if we
>     forbid the client talking to the telepathy daemon well known name.

In principle everything should cope gracefully with not being able or
allowed to talk to the relevant services. The main place to "cut the
trace" (and verify that things still work) is client <-> Mission Control
5, because well-behaved clients won't talk directly to a connection
manager that isn't providing a Mission Control account.

If you don't actually *want* Telepathy (I don't know what you're
shipping) then a --without-telepathy configure option for e.g. Shell, or
runtime detection if it's all done via g-i, seems sensible. If you're
linking libtelepathy-glib.so.0 into C code then it would have to be a
compile-time option whether to do so.

Telepathy used to have "everything over D-Bus, nothing assumes a shared
filesystem" as a design principle, which is still the case in many
places; but that might have been partially abandoned in more recent
versions (e.g. in favour of mandating a shared avatar cache), on the
basis that nobody actually used it like that and so it was wasted
effort... basically, the more requirements people have for Telepathy to
jump through hoops to work across container boundaries or stay
backwards-compatible or whatever, the more of its maintainers' time it
will take to get anything done. Like anything else, it's a trade-off.

>     Could we do something between "full access" and "nothing" though?

The major privilege represented by Telepathy is "can impersonate you on
instant messaging services". Is that acceptable for your use case or not?

In principle it's possible to do more elaborate filtering (e.g. Maemo
would allow all apps to talk to most Telepathy services, but had special
permission checks for phone calls and SMSs because those cost money) but
this requires someone who wants that feature specifying it and doing the
work.

>     Are the telepathy dbus ABIs backwards compatible? For instance, if I
>     have some installed app that ships the 3.16 client libraries, but the
>     host is running the 3.18 dbys services, is this guaranteed to work?

For Telepathy 0.x (x < 99) it's meant to work with either direction of
mismatch, which is why our recommendations for the Telepathy versions
that should be shipped with each GNOME release were only
recommendations, not requirements. There will be some "graceful
degradation" if your D-Bus services and your client library and UIs are
different ages, but it shouldn't be anything serious as long as both are
> = 2010 or thereabouts. If one side is *really* old, then you start to
get into incompatible dialects for major features like VoIP and
presence, and UIs will behave as though those features were not present.

Telepathy 1 (for which 0.99.x are prerelease snapshots) is not
compatible at all: it's parallel-installable and has a new set of APIs,
in the same sort of way that Gtk3 is incompatible with Gtk2. The D-Bus
APIs' names are all different, so Telepathy 0 and Telepathy 1 don't
"see" each other at all. Tp1 is unfinished, and I am not aware of anyone
actively working on it; I was, but I don't have any time-budget for it
at the moment, and I'm not sure whether I ever will.

> I know for sure that the Telepathy folks have traditionally payed a lot
> of attention to backwards compatibility though.

Yes, we have. However, one result of that attention to backwards
compatibility is that Telepathy was increasingly time-expensive to work
on (ye olde APIs are expected to keep working even though they're
awful). Telepathy 1 was an attempt to fix that by clearing up
accumulated technical debt.

>     Also, this essentially adds a new requirement on the host os session
>     when running this particular runtime (has telepathy >= 3.16 installed).

Do you actually need Telepathy for your mysterious use-case?

Is "if the host OS doesn't have vaguely recent Telepathy, then
presence/IM/VoIP don't work" an acceptable fallback?

    S