----- Original Message -----
Hi,
On Fri, 2018-02-16 at 04:50 -0500, Bastien Nocera wrote:
> No, the Flatpak and host are separate. I'm guessing that you're
> worried about mismatches between evolution-data-server and its
> clients.
Heh, you just say 'no' and then change it to 'yes'. Some applications
do depend on system services, regardless what they are built against.
Sorry, it was clearer in my head. The "no" applies to library APIs, the
"yes" applies to D-Bus "remote" APIs.
> There's really no other way to make this work than to work
towards a
> stable, and versioned API.
It's not about API by any means. The (D-Bus and code) API can be
stable, but the underlying code can change. I know that software like
GNOME Calendar and GNOME Contacts and others use mentioned evolution-
data-server (eds) and they compile against some version, but then use
the host version of the D-Bus services. It's fine as long as you do not
care of functionality. It happens often that some bug is noticed on the
client side (being it GNOME Calendar, GNOME Contacts, Evolution,...),
but the actual fix for it lands in the eds, like into the builtin
backend. This fix doesn't change API, no soname version bump needed, no
D-Bus service version number increased). That means that the Flatpak
version can be built against eds which has the bug fixed, but whether
it's truly fixed depends on the host system.
That will be the case for any host-side feature, especially the ones that
rely on online services (gnome-online-accounts is probably another), or
the ones that rely on hardware-related bug fixes. That's par for the course,
and that will probably mean more backporting and stable releases.
That's odd. Adding eds
into Flatpak is not correct from the point of sharing the same data
between various applications and the system (GNOME Shell) itself
(unless some portals of Flatpak or what that idea to catch on this was
named).
On mobile, this would be split up more, so the calendar backend would live
in the Calendar app, the Notes backend in the Notes app, etc. This leaves
the sign-on on the host side. But they can do that because they have blessed
front-ends which we don't in GNOME or Fedora.