RFC: On-demand package installation API in kdelibs

[Lubos Lunak]

On Thursday 29 of July 2010, Kevin Krammer wrote:
> On Thursday, 2010-07-29, Lubos Lunak wrote:
> > On Thursday 29 of July 2010, Kevin Krammer wrote:
> > > Installing things, especially when potentially involving  downloading,
> > > is inherently asynchronous.
> > > So such an easy method either returns immediately and provides some
> > > kind of status signalling or it uses nested event loops.
> >
> >  Nested loops. Just like e.g. KMessageBox does, so there is nothing
> > inherently wrong with it. And there are many cases where it's much
> > simpler to just block on the call and wait for the situation to be
> > handled before proceeding.
>
> Sure, but (a) there is trend away from blocking message boxed towards
> notify and continue

 You can't really notify and continue if you first need to wait for something 
necessary for the proceeding.

> and (b) developers are usually aware of the ongoing event loop processing
> with modal dialogs. 
>
> It is always possible to "block" an asynchronous call by doing a nested
> eventloop manually, but it is impossible to unblock a nested eventloop or
> even know that one is being used without looking into the code.

/**
 * This call is blocking and may re-enter the event loop. Use the asynchronous 
startFoo() variant if you do not want this simple API.
 */

>
> A bit following "principle of least surprise", applications using other
> eventloop driven operations like socket I/O will get unexpected re-entrancy
> despite being a single threaded application.
>
> Does the current implementation handle multiple invocations?
> E.g. KMail calling it to install something and while it is
> downloading/installing a signed message arrives an KMail calls it again to
> check/install GPG

 Possibly, I don't know.

-- 
 Lubos Lunak
 openSUSE Boosters team, KDE developer
 l.lunak at suse.cz , l.lunak at kde.org