RFC: On-demand package installation API in kdelibs

[Kevin Krammer]

On Thursday, 2010-07-29, Lubos Lunak wrote:
> 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.

Well, true, if it is something you absolutely need before you can continue.
But in this case it should be a package dependency and not be allowed to be 
absent.

I though this was about installing optional things that could be installed and 
enabled once present.

> > 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.
>  */

How about startFoo() and waitForFooStarted()? As in keeping API similar to 
already established API (QTcpSocket, QProcess).

> > 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.

Should be easy to test by queueing a method invocation (or delaying with a 
single shot timer) just before calling the function and let the invoked method 
try to install a second package.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100729/398cb4d4/attachment.sig>