[WebKit-devel] RFC: API for KWebWallet...

[Dawit A.]

On Friday 06 November 2009 04:48:00 David Faure wrote:
> On Friday 06 November 2009, Michael Howell wrote:
> > On Thursday 05 November 2009 15:59:28 Dawit A. wrote:
> > > Hi all,
> > >
> > > Attached is the first take for a QtWebKit/KWallet integration class,
> > > KWebWallet, I am currently working on. The functions present there are
> > >  mostly documented, but some bits and pieces are current missing. Note
> > > that there is no implementation of this class yet! This is only my
> > > attempt to get the API worked out first...
> > >
> > > I have purposefully kept the API I created as simple as possible. You
> > > call saveFormData, most likely from acceptNavigationRequest when the
> > >  NavigationType is NavigationTypeFormResubmitted, to save the form data
> > > and to restore it you would probably connect the
> > > restoreFrameStateRequested QWebPage signal to the restoreFormData slot
> > > from this class.
> > >
> > > However, the above is only my approach and I need feedback a what
> > > people want to get from this API...
> >
> > Why not, instead of using a signal on the KWebWallet object, return a
> > KJob or a QFuture from the saveFormData, like, for example,
> >  QNetworkAccessManager (I know, it actually returns a QReply...) and KIO
> >  do.
> 
> I don't understand how this can be implemented with a QFuture (which seems
>  to be only for threads, and only implementable by Qt itself?).

It can be implemented using QFuture. It would simply mean that this class 
defers the decision and the work of whether or not the call should be async or 
not to the caller itself. In other words, the caller can choose to call 
result() on what the saveFormData function returns and block waiting for the 
result or it can choose to use QFutureWatcher and become non-blocking. Of 
course, QFutureWatcher uses signals/slots. 

Now, whether or not putting the burdern of doing more work on the users of 
this API is of course debatable. Eventhough, I like Michael's idea and think 
it is great from the prespective of developing this class, I am not entirely 
conveniced that this API should defer any extra work it can easily do itself 
onto the users of this API. And yes I do consider the work the caller has to 
do to make the return async through QFutureWatcher, which it would not 
otherwise have to do, extra work.