[packagekit] Res: Res: Session D-BUS API

Daniel Nicoletti dantti85-pk at yahoo.com.br
Sat Mar 7 17:26:58 PST 2009

>> K, i think me and trever are a bit out of sync..
>> First we don't need qpackagekit to be sync,
>> QDbus does async for us.
>I'm not referring to qpackagekit, or even PackageKit-Qt. I'm talking about the 
>session side D-BUS API.

well you said in jabber that packagekit-qt should be sync,
and i'm sayind it don't need to QDBus can be sync.

>Er, which method exactly are you advocating? Or are you saying that we should 
>have a sync and an async API? Implementing an async API would basically be the 
>same as making packagekitd available on the session bus. After reading 
>Richard's explanation of this stuff, I agree a synchronous API is best. In an 
>app, making a quick internal event loop to handle GUI events while waiting for 
>a dbus reply is pretty simple.

Yes, pretty much making packagekid available at session side
the only and most important difference is that all the dialogs and logic
is done by gpk/kpk.
Using DBus in syncronous mode in not an option for me, i'll not add this
to kpk, Polkit already has it and even there that the dialogs are faster
i find this good.
If you don't know the problem with this approach it's pretty simple,
all DBus calls has a timeout that can be set to MAN_INT, i read
in some place that this could be tunned but even if it's true i prefer
async... this way an app can ask for a plugin and continue to work
normally, after we finished installing it the app can show a dialog,
load the plugin....
So the solution imo should be a simple async interface.


      Veja quais são os assuntos do momento no Yahoo! +Buscados

More information about the PackageKit mailing list