[packagekit] PackageKit Proposal: Session Interface

[Sebastian Heinlein]

Am Donnerstag, den 31.05.2012, 19:45 -0300 schrieb Daniel Nicoletti:

> The problem:
> As all transactions are queued by packagekitd, it's impossible
> to do a search while installing/updating or actually doing anything
> else, you have to wait for the installation to complete, which
> might take a while...
> [...] 
> My proposal:
> Reuse all we have in packagekitd and create a session
> helper/daemon, all our backends already have the features
> we need, but we don't necessary need to use then only from
> one process.

What comes to my mind:

Since the client application cannot decide which daemon to use (the
system or the session one) for each used backend/package manager the
session daemon could provide all methods of the current system bus
having its own backends. The session bus would be the only interface the
client application has to care about.

If a transaction requires root privileges the session bus could call the
system daemon and proxy the results. The backends would decide which
would be the best behavior.

I am not afraid of keeping a second copy of the cache open in the
session bus. This is already done by QApt or software-center. I am more
afraid of keeping a second sqlite cache inside packagekit. PackageKit
should stay a thin layer.

Which package managers could support having the cache opened twice? Does
any backend require root privileges to access the cache?

> This way you do searchName("foo bar", "~installed;free"); the backend
> searches and emit the packages like it does today but instead of
> packagekit forward the signal the packages are appended to a list and later
> returned to the caller. In aptcc my tests have showed that one the things
> that wastes more time is emitting signals of packages. It has a bunch
> of marshmallows to do :P

Having a Packages signal next to the currently existing Package signal
which would allow to send an array would be a benefit. So you could emit
Packages signals in junks of 100 or 1000 packages.

> Being sync is less work for the session-interface, it's less work for the
> callers and should really be faster, and after all we won't be able to use the
> session interface concurrently anyway.

Blocking calling applications is really a no-go nowadays. Re-using the
transaction concept seems to be a good idea. This would allow to reuse
code from the existing backends and to run system and session
transactions side-by-side.

Most client applications won't access the DBus API directly but use the
glib based client with optionally GObject Introspection or the QT based
one. So you could even conserve some API here.

Cheers,

Sebastian