On Tue, 16.09.14 13:35, Petr Pisar (ppisar@xxxxxxxxxx) wrote: > On 2014-09-16, Richard Hughes <hughsient@xxxxxxxxx> wrote: > > The much bigger issues is if you're using a D-Bus service > > like most applications seem to do (and most use quite a few system and > > session, directly and indirectly) then you've also got to co-ordinate > > and handle changing D-Bus API (which typically isn't versioned). > > Maybe it's time to version the API. > > Look at microkernel based systems which utilize messaging heavily and > the API consumers (applications or another subsystems) have to be > prepared for spurious API provider (server) restarts. > > A server can refuse a message any time (especially if it does not > understand the request). Simple operations are usualy implemented as > a sequence of requests and responses where initial request obtains > a descriptor (a session, a handle) and subsequent requests passe it as > context (a session) identifier. If the server is restarted in between, > the context identifier becomes unrecognized and it's up to the > application to deal with it. > > Just the fact that somebody calls functions over dbus instead of jumping > into a shared library do not free them from maintaing API. Well, the theory for this might be great. But reality tells us that code that isn't regularly tested tends to be broken. Hence: the assumption it would be reasonably possible to comprehensively test all kinds of updates between any combination of software versions, executed in any order, simultaneously with the user using the machine, then is simply wrong. You explode the test matrix, and without testing such upgrades will never be reliable. The offline update logic is about making the test matrix smaller, and adding determinism where it normally is missing. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
