[packagekit] PackageKit API changes

[Daniel Nicoletti]

Hi list,
as you all know PackageKit changed it's API quite a
lot in the past (which is ok in my POV since the
project was starting). Right now PK is used in several
distros and developers are trying to use it more and more.
And the first complain I hear (one of these from openSUSE)
is that API changes too much.

So there are a some signals that I trully never liked, especially
because you can't "read" the code bellow:

THIS connects the UpdateDetail SIGNAL
     connect(d->p, SIGNAL(UpdateDetail(const QString&, const QString&, const 
QString&, const QString&, const QString&, const QString&, const QString&, const 
QString&, const QString&, const QString&, const QString&, const QString&)),
            d, SLOT(updateDetail(const QString&, const QString&, const QString&, 
const QString&, const QString&, const QString&, const QString&, const QString&, 
const QString&, const QString&, const QString&, const QString&)));

THIS connects the Details (package details) SIGNAL:
connect(d->p, SIGNAL(Details(const QString&, const QString&, const QString&, 
const QString&, const QString&, qulonglong)),
            d, SLOT(details(const QString&, const QString&, const QString&, 
const QString&, const QString&, qulonglong)));

That's C++ with Qt, and if you look at the glib version isn't easier at all.

So what if tomorrow we decide that Details needs to pass the size
of the installed package and it's popularity?
API breaks.

This is not good, since every app on earth that needs just to get
the package description (which doesn't care about popularity at all),
will have to be fixed.

My proposal as I said to Richard and of course any of if in case of a
better idea please say. is:

 * Deprecate Subpercentage property.
 * Deprecate these two methods.
 * Deprecate Package() signal.

And from these 3 signals we get just one:
 PackageData(string package_id, string status, stringlist data)

Richard said that he doesn't want backends emiting any kind of
data, otherwise (as I think) it would let some specific frontends
or non-compilant ones to be written, which is indeed bad.

The solution would be to verify all the data emited by the
backend to see if it is ok, so if someone sends "special" data
it gets dropped. This is an expensive solution though. But
if we use enum numbers it can be reduced.

Now some use cases for this signal:

// emit that the download of package foo is at 30% [1]
PackageData("foo;3.3.3;bar;zing", "downloading",
      ["progress=30", "progress-bytes=3294", "bytes-total=393423"]);

// emit update info
PackageData("foo;3.3.3;bar;zing", "security",
      ["issued=3423540", "updates=foo;2.2.2.2;zing;bar", "changelog=this update 
is important because it extends our API"]);

// emit package details of popularity
PackageData("foo;3.3.3;bar;zing", "security",
      ["description=This package is nice", "popularity=87"]);

Then we creates an enum PackageData fields PK_ENUM_POPULARITY and use them
in the code.

[1] This actually fixes a bug in PK when multiples downloads are running
the progress of them is mixed since Subpercentage does not tell us which
package has the percentage.

Any thoughts?

Best,________________________________
Daniel Nicoletti - KDE Developer
http://dantti.wordpress.com
When a wicked man dies, his hope perishes;
all he expected from his power comes to nothing. Prov. 11:7


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20101125/e0ddeca2/attachment-0004.htm>