On Wed, 19.09.12 13:12, Colin Walters ([email protected]) wrote: > [I just joined the list, sorry if this has been discussed before...it's > hard to search for] > > So what's the big picture rationale for why some APIs are DBus (quite a > lot), others are raw AF_UNIX (scheduled shutdown), and others are > basically an "API" where named files are put in specified places (system > update)?
Well, a number of reasons apply to the various cases. It really depends on the specific area what the best API is. One point is that synchronous APIs are often nicer to work with than asynchronous APIs. We should be careful not to think "I have D-Bus, so everything is a D-Bus problem now". It also sometimes is due to perfomance reasons. For example clients read the journal files directly, because the format is designed to be mmap()able, and the data is substantial. It would simply be inefficient to use sockets for that, or even D-Bus. (I mean, it's the same story why dconf goes directly to disk for the reading side.) In other cases this also has something to do with the fact that the D-Bus daemon is around only very later in the systemd, and goes away early on shutdown, but we need some service around even then. For example the scheduled shutdown stuff is of this kind. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
