Re: evolution-data-server D-Bus service version change in 3.29.3
On Fri, 2018-06-08 at 13:27 +0100, Simon McVittie wrote: > > (This also prevents use of generated bindings; any method which a > client wants to gracefully fall back from should be called using > a generic D-Bus method invocation rather than a specific generated > binding.) > > and I'm not sure why. I've opened > https://bugs.freedesktop.org/show_bug.cgi?id=106862 to try to clarify this. If the generated bindings are in a library that properly uses symbol versioning (which much of GNOME unfortunately seems to eschew), and if the client library is shipped along with the service, it should all work out fine. Just adding the new API to the client library and not having any proper symbol management, of course, is just the same problem we have elsewhere and not at all DBus-specific. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: evolution-data-server D-Bus service version change in 3.29.3
On Fri, 08 Jun 2018 at 09:03:26 +0200, Milan Crha wrote: > this is a little heads-up that evolution-data-server 3.29.3 release > will contain a D-Bus service version change, specifically >org.gnome.evolution.dataserver.Sources5 > changes to >org.gnome.evolution.dataserver.Sources6 > > This had been done due to adding a new method to the interface for [1]. > I'd not bump soname version for such API addition, but the D-Bus > service is a different thing. Just to confirm what was already said: this change does not require the D-Bus interface version to be increased, and it is unnecessarily disruptive to do so, so I'm glad you reverted the change. If this was needed, systemd's various services would look more like org.freedesktop.login25 by now :-) With D-Bus maintainer hat on, if there are D-Bus client libraries that do not cope gracefully with a method not being present, then I think those libraries are broken. D-Bus services should raise UnknownMethod if a client tries to call a method that doesn't exist, and should raise either UnknownMethod or an appropriate domain-specific error if the method is known to the D-Bus library but not implemented in application-level code. IPC clients (including D-Bus) have to cope gracefully with IPC errors *anyway*, because IPC can fail for various reasons, and it would be bad for clients to be remotely crashable by their services. https://dbus.freedesktop.org/doc/dbus-api-design.html has some useful advice on designing and versioning D-Bus APIs, although I notice that it currently says (This also prevents use of generated bindings; any method which a client wants to gracefully fall back from should be called using a generic D-Bus method invocation rather than a specific generated binding.) and I'm not sure why. I've opened https://bugs.freedesktop.org/show_bug.cgi?id=106862 to try to clarify this. > I'm mentioning it here, because this influences at least Flatpak builds > of projects using evolution-data-server, like gnome-calendar, > gnome-todo and gnome-contacts, which build against the latest eds, but > run backends from the host machine (thus they do not receive all the > fixes). The Flatpak builds should be adapted accordingly. Sorry, you can't do that. If a Flatpak app like gnome-contacts wants to use a service like evolution-data-server from the host system, then evolution-data-server and gnome-contacts need to stay backwards-compatible with each other: either one might be newer, depending where you got your gnome-contacts and evolution-data-server. smcv ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: evolution-data-server D-Bus service version change in 3.29.3
On Fri, 2018-06-08 at 09:42 +0100, David Woodhouse wrote: > I don't *assert* that it was unnecessary... but I kind of *hope* it > was unnecessary... Hi, you are right, it was unnecessary. I gave it a try (I really shouldn't be that lazy) and the GDBus proxy doesn't panic when some method is not available (I've been afraid that the application will not run), it only errors when the method is called with something like: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method 'RefreshBackend' which is perfectly fine from my point of view, thus I changed the D-Bus version back. I'm sorry for a false call. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: evolution-data-server D-Bus service version change in 3.29.3
On Fri, 2018-06-08 at 09:03 +0200, Milan Crha wrote: > > If you think the D-Bus service version bump was unnecessary, then I > will revert it. I only thought that it was cleaner, because the C API > function will not fail due to missing D-Bus interface method (to be > honest, I do not know what the GDBusProxy will do when the running > interface doesn't contain all the methods it expects to have). Hm, isn't this what we have introspection for? I don't *assert* that it was unnecessary... but I kind of *hope* it was unnecessary, and if it really was necessary then I'd hope someone is fixing things so that in future it *wouldn't* be necessary. :) smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
evolution-data-server D-Bus service version change in 3.29.3
Hello, this is a little heads-up that evolution-data-server 3.29.3 release will contain a D-Bus service version change, specifically org.gnome.evolution.dataserver.Sources5 changes to org.gnome.evolution.dataserver.Sources6 This had been done due to adding a new method to the interface for [1]. I'd not bump soname version for such API addition, but the D-Bus service is a different thing. I'm mentioning it here, because this influences at least Flatpak builds of projects using evolution-data-server, like gnome-calendar, gnome-todo and gnome-contacts, which build against the latest eds, but run backends from the host machine (thus they do not receive all the fixes). The Flatpak builds should be adapted accordingly. If you think the D-Bus service version bump was unnecessary, then I will revert it. I only thought that it was cleaner, because the C API function will not fail due to missing D-Bus interface method (to be honest, I do not know what the GDBusProxy will do when the running interface doesn't contain all the methods it expects to have). The evolution-data-server pkg-config file contains service names for couple releases already, thus one can use: $ pkg-config --variable=sourcesdbusservicename evolution-data-server-1.2 $ pkg-config --variable=addressbookdbusservicename evolution-data-server-1.2 $ pkg-config --variable=calendardbusservicename evolution-data-server-1.2 $ pkg-config --variable=userprompterdbusservicename evolution-data-server-1.2 to get the service names the evolution-data-server expects to have. Bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=795197 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
