akonadi and it's impact on kde

[Volker Krause]

On Wednesday 25 February 2009 12:58:31 Kevin Krammer wrote:
> On Wednesday 25 February 2009, Volker Krause wrote:
> > On Tuesday 24 February 2009 23:34:07 Michael Jansen wrote:
> > > Because of commit
> > > http://websvn.kde.org/trunk/kdesupport/akonadi/server/src/akonadi.cpp?r
> > >1= 92 2019&r2=931063 my akonadi failed to start. That's generally spoken
> > > no problem. We all sometimes commit something that doesn't work.
> >
> > Fixed in revision 931461, also backported to the Akonadi 1.1 branch.
> >
> > > Kontact didn't show up at all. It run in the background but the gui
> > > didn't come up.
> > >
> > > There was no way to find out that a missing akonadi was the problem.
> >
> > Kevin, isn't there a Akonadi::Control::start() call in the compat bridges
> > that should have brought up the self-test dialog in case the server is
> > not available?
>
> There is one in ResourceAkonadi::init() (for both resource types), called
> by both constructors.
> However it is the one without QWidget parameter since the plugin doesn't
> know any widget.

You can always pass 0 for the parent widget parameter, assuming we don't use 
the resource in a gui-less context anywhere.

> > > We should make sure that a missing helper application doesn't make the
> > > kde desktop unusable. I can't even begin to imagine the bug reports if
> > > such behavior happens to an end user.
> >
> > Obviously, this is not intended. Therefore, it's actually good that this
> > happend now and we can fix it long before any user will ever see this.
> >
> > The background here is that the affected applications are still using the
> > old KResource-based synchronous API to retrieve the addressbook, which
> > can cause problems like the one here. Which is one of the reasons for
> > starting the development of Akonadi in the first place.
> >
> > Kevin, I see two options to deal with a server connection loss in the
> > synchronous job execution code: Add an option to Akonadi::Session to
> > abort in this case instead of retrying or monitor the server status
> > manually. The first seems easier and more robust.
>
> An additional parameter would either have to be added to the jobs or
> require manually creating a session object an pass that to the job as
> parent, right?

It could also be a just setter method in Session. If you call it before any 
job has been started, everything is fine,  if not the worst case is that it 
takes half a second (or whatever the current retry timeout is) until it takes 
effect. The default session is available via Session::defaultSession() and is 
a per-thread singleton IIRC, so it would also only affect the jobs started in 
the worker thread in this case.

> > Still, we shouldn't get that far
> > anyway, if Akonadi::Control::start() fails.
>
> My mistake I suppose. The result of Control::start() is not used. I am
> working on a patch.
>
> > > Back to the wrong commit: line 236 It goes to the else section too if
> > > there is no need to update the conf file.
> > >
> > > @rdieter: I would have fixed it, but i can guarantee i would have not
> > > adhered to the coding style so please do it yourself.
> >
> > As far as I am concerned, a quick fix is more important in such cases as
> > following the coding style...
>
> I agree.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090225/9de86b8e/attachment.sig>