[packagekit] PackageKit Proposal: Session Interface

[Daniel Nicoletti]

2012/6/1 Sebastian Heinlein <devel at glatzor.de>:
> Am Donnerstag, den 31.05.2012, 19:45 -0300 schrieb Daniel Nicoletti:
> What comes to my mind:
>
> Since the client application cannot decide which daemon to use (the
> system or the session one)
How can't it decide? You have to explicity tell which bus you want to use,
I'm not talking duplicating packagekit on the session, it's just that all
methods used to query the cache would be there
like search(name, details, file), resolve, getPackages()...

> 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.
We need fast things, proxing stuff brings all kinds of problems

> 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.
Then we would have an security issue since the caller will be the
trusted session helper and not the actual application

> 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.
Why do we need another sqlite cache? (that's not what I'm proposing)

> Which package managers could support having the cache opened twice? Does
> any backend require root privileges to access the cache?
All of them? can't you yum search, zypper search, apt-get search... as user?


>> 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.
I don't see the benefit of worrying about spliting a package list, I can
compute them in a very short time.

>> 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.
Reusing the code of the existing backend is what I'm proposing to do,
blocking calls on DBus don't mean you code will block,
they can just enter on the event loop. We already have this with
PackageKit session interface implemented in Apper/GPK

> 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.
Well we are breaking API for PackageKit 0.8, so the libpackagekit-qt and
the glib one will change, and on the Qt side I can even do all this transition
without breaking API, but since there are AFAIK only two users of the
qt lib I don't care much.

Cheers.