[packagekit] Res: Session D-BUS API

[Daniel Nicoletti]

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 finalizing the last bits of polkit-qt yeah,
we are going to release this weekend.. i just need
to finish a bit here..

after that i want to work on the dbus interface,
and as discussed before the way call and way
to be finished imo does not work, so imo it's
much better to provide a simple interface,
that calls and exit imediatally, with signals
that tell the status, finish.
MAX_UINT is too short and ppl will start thinking
this is our bug.

i vote to have a simple asyinc lib.. 
installPackage installFont
statusChanged -> canceled, finished, downloading, waiting..

and maybe a cancel..

imo this should be enough..


Daniel.



----- Mensagem original ----
De: Richard Hughes <hughsient at gmail.com>
Para: PackageKit users and developers list <packagekit at lists.freedesktop.org>
Enviadas: Sexta-feira, 6 de Março de 2009 14:12:46
Assunto: Re: [packagekit] Session D-BUS API

On Fri, 2009-03-06 at 09:46 -0500, Trever Fischer wrote:
> I've managed to find a bit of time between classes and trying to get elected to 
> student gov't here to start implementing the D-BUS methods for KPackageKit. 
> I've got a couple of questions about it though:

Well, good luck with the elections :-)

> 1. Are methods such as InstallLocalFile, InstallCatalog, etc supposed to be 
> syncronous?

Yes.

> Eg, if an app calls them, should it wait for them to complete 
> before going on and assuming the job completed? I think it'd be easier to 
> implement if they all returned some kind of job ID, and a jobComplete(id) 
> signal got emitted, since the packagekit calls are already asynchronous.

I thought about that, but i really wanted the interface to be
fire-and-forget in that an application just called into the interface,
and it returned with success or failure. This needs to be kept very
simple for most apps.

> Then 
> it'd be up to the specific app developer if they really want the calls to be 
> synchronous or not. I mostly make this point because I'd rather not have a 
> bunch of event loops floating around in kded to convert the native async calls 
> to sync ones.

Yes, lots of event loops are icky.

> The exception of course is IsPackageInstalled.

Sure, but bear in mind this can block for a few minutes too if
packagekitd is servicing other transactions.

> 2. What is InstallProvideFile supposed to do? Is it supposed to search the 
> list of available files for whats needed? Shouldn't whatProvides() be able to 
> handle that?

It literally installs a package that provides the file /usr/bin/foo.
Basically, it's a way for an application to say "I need $this_file --
JUST DO IT" and not worry about all the details.

> 3. What are the xid and timestamp arguments for? Am I correct in assuming xid 
> is an X11 window ID?

Well, you don't need to copy the "old" interface with the timestamps,
and yes, an XID is used to make the download window modal over the
window that launched the window. If the method is async, it also makes
doing that harder. FWIW, I think the max bus timeout is now pretty long
as  long as you set it to MAX_UINT, but I am open to other ways of doing
it as the session methods need to be cross desktop.

Thanks,

Richard.

Richard.


_______________________________________________
PackageKit mailing list
PackageKit at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/packagekit



      Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com