Improving the offline updates user experience

[Lennart Poettering]

On Tue, 16.09.14 13:35, Petr Pisar (ppisar at redhat.com) wrote:

> On 2014-09-16, Richard Hughes <hughsient at gmail.com> 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