[Kde-pim] Akonadi Resource - setOnline troubles

[Daniel Vrátil]

On Sunday 23 of February 2014 19:53:34 Martin Koller wrote:
<snip>
> > 
> > From the outside perspective they are probably the same.
> > Akonadi server should not send any requests to a resource in either state,
> > the already scheduled request will not be processed for now.
> > 
> > > When a resource wants to contact a (network based) server, and it can
> > > not be reached (for whatever reason. No net at all, or simply currently
> > > not possible, or even: the server is reachable but answers with some
> > > error), the resource should notify the user (by a state and some error
> > > message) that it currently has a problem with the communication, but it
> > > will automatically retry again (either because of a timeout or Solid
> > > tells us the network is here again).
> > 
> > I don't think the immediate reaction is the same.
> > When the server responds with an error, this error needs to be reported.
> > When the problem is no net or not contect, then be better not to.
> > E.g. if the network connections does down, the user will usually get a
> > notification from the network applet.
> > There is probably also no need to report every failed connection attempt.
> 
> AFAIK the message a resource produces is only shown in the resource
> configuration widget (e.g. kmail settings, accounts).
> I think I have never seen a message from the DAV resource in the knotify way
> (system tray area) (I mean messages from cancelTask() or "emit
> status(...)")
> So this is not intrusive but the user still can check why a resource is
> currently "disconnected"


You have to have Akonadi Tray running. Then you get lots of annoying 
notifications and errors :-)


> > What about naming those non user states more like a socket:
> > 
> > Disconnected, Connecting and Connected.
> > 
> > If the resource code handles the Disconnected -> Connecting transition,
> > then all states "below" are of no concern to most resource implementers.
> > I.e. the implementation doesn't care whether the transition is not coming
> > before the user chose StayDisconnected or whether the network does not
> > come online, it only attempts connection based on the transition event.
> > 
> > If it fails -> Disconnected, probably starting retry counter to report
> > error when giving up. That can probably even be built into base.
> > 
> > If it succeeds -> Connected.
> > 
> > If it observes Connecting -> Disconnected or Connected -> Disconnected, it
> > just stops, no eror (either user intervention or system intervention).
> 
> I'm not sure if we need these additional states at all.
> As they are just temporary states, who cares. It's the message of progress
> what matters to a user.

We need Connected and Disconnected states for obvious reasons and then you 
need to have a state in between them, since there is no direct transition from 
Connected -> Disconnected. Otherwise the resource would be in an undefined 
stated while connecting. This does not have to be user-facing, but internally 
you want to have such state IMO.

> E.g. the user defines the resource shall either be "enabled" or "disabled".
> If the resource can currently reach the server (the backend) or not should
> not change its (online) state. It should be enough to let the user know
> with a message "... had problem to contact the server; last operation
> failed, etc.) as long as the resource just does it's best to retry until it
> finally succeeds and stores all changes in the meantime.
> 
> My solution with setTemporaryOffline() is probably just a bad name for what
> I want to achieve. I do not want to set the resource to offline (or
> disabled) at all, I just want to tell the resource to activate the change
> recorder queue and store all changes and start to retry to empty that
> command queue until it can finally
> send these to the backend (I hope I use the correct terminology).
> The "state" it is in during that "problematic phase" is still "enabled" (or
> online) but it should report a status/message of "Broken".

The ChangeRecorder is active all the time and it's actually up to 
ResourceScheduler to read Notifications from it. ResourceScheduler will not 
request more Notifications from ChangeRecorder, when the resource is offline.

> Whereby this alone is already confusing.
> There is the online/offline state and there is yet anonther "state" the
> resource can be in, which is described in the Status enum. And I think I
> have seen that the widget used in showing the "state" (green circle when
> onnline, etc.) is just mixing these two "state/status" things in one icon,
> which is also very bad.
> 
> And "NotConfigured" as Status is even worse. How can a resource ever be set
> "enabled" (online) when it was not configured ?
> 
> So I think online/offline is just a bad name for "the user has enabled or
> disabled the resource". Everything else is just a temporary situation the
> resource discovered while working when set to "enabled".

Indeed, that why we want to have multiple states, as I explained in the 
previous email.

> 
> Back to my original problem: is there another way of telling the resource to
> "enable the change recorder" than to switch it to "offline" ?
 
See above, just setOnline(false). Everything else is already there.


Generally, I agree that having Online/Offline states and then Status state is 
confusing and makes this complicated. We can't do much about it now, but we 
can rethink this approach for KDE Frameworks.


Dan

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140301/20648ba2/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/