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 Wednesday, 2010-07-28, Lubos Lunak wrote:
> > >  So the idea is to provide simple API in the form of 'bool
> > > 
> > > tryToEnsureInstalled{MimeType|Binary|Whatever}( QString name )'.
> > > Various KDE code will call it when it finds out something is missing
> > > and maybe the call solves the problem.
> > 
> > While I like the idea of making it easy for developers to incorporate
> > such a feature, I am afraid that this stile of API is simplified to
> > much.
> > 
> > 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 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.

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

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/2c4c2923/attachment.sig>