RFC: On-demand package installation API in kdelibs
Kevin Krammer
kevin.krammer at gmx.at
Thu Jul 29 16:42:07 BST 2010
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>
More information about the kde-core-devel
mailing list