[packagekit] PackageKit Proposal: Session Interface

[Daniel Nicoletti]

Hi all,

with the upcomming 0.8 version of PackageKit I think
it's good time to talk about my proposals. I have talked
to Richard on IRC but it's nice to see if someone else
has different/better ideas :D

PackageKit is nearly on every distribution out there surely
a thing no other project achieved before, this was a very big
step. With the large deployments of Software Stores it is
completely acceptable to see that distros interested in
surviving want to have that feature.

KPackageKit/Apper lost a default installation on Kubuntu
partially because of that, tho I've added screenshots & friends
it's not possible to completely reproduce Ubuntu Software
Center due to our API/daemon/backend limitation.

Right now, Matthias is working on a "work around" for having
USC running with PackageKit on openSUSE, I call it a work
around since he's creating an index of all package cache thus
duplicating the cache and consuming resources. He has a
GSoC to deliver a working solution, so there isn't a better
alternative for this right now.

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 first idea to fix this issue was the most obvious one: Threads!!
but probably most backends (including aptcc - the one I care most)
don't support threads, in apt case we have some global variables
that will get shared by threads, I even got to this problem without
even using threads... lol

So fixing all our backends isn't to me a solution, because this
will not only take years to be available to every distro but also
for the changes to get accepted upstream.

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.

The baddies:
* Change our GUIs
* Create a new program
* Find new bugs

The goodies:
* The package cache can be kept open during the
  life time of the process, only reopening if it gets dirty.
* The session daemon interface won't create objects path making
  it easier for other apps to use it directly
* We won't have to worry about the number of packages one
  ask to resolve in packagekitd. (this won't block packagekitd)
* Less privileged code running
* More clear behavior of the Proxy (since some backends insist
  in refresh the cache on search, which isn't supposed to have
  the Proxy set)
* PackageKitd queue would only be for package operations, thus
  allowing to prioritise them (ie off line updates later)
* Less duplicated code in Gnome PackageKit and Apper.
  Let me explain this last one:

Right now when an application like a video application wants to now
if foo codec is installed this is what happens:
[ Video APP ] -> [ GPK / Apper ] -> [ packagekitd (queue) ] -> [ backend ]

These steps would become, not only sorter, but also the Video App
won't have to wait for a install to finish just to now if the codec it needs
is available.
[ Video APP ] -> [ packagekit-session ] -> [ backend ]

The Session API:
In Apper I had done several tests trying to improve the speed,
when doing large queries like get all installed packages it became
much, much faster, 5x ~10x faster when I added all results at once
instead of one by one to the list, because the ui didn't had to
recompute the scrollbars the column size every time a package
arrived, and then resort the packages.
I'm confident we can increase package search on pretty much
on every backend, this is why I'd like the session interface
to be sync.

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

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.

I'm just a bit unsure of the return types since a{ssss} might be trick to work
with...

An alternative to sync could be cookies, where you connect to the desired
signals, and when you call searchName(...); you get a cookie, then your
callbacks (slots), just check if the cookie of the given emitted package
matches the one of the call.

Or at least create transactions the current way.

PLEASE put you brain to work and make suggestions to this :D
IMHO it's very important for the future of this project to be able to
browse while doing package cache operations.

Thanks,
Daniel.