[Kde-pim] Akonadi Resource - setOnline troubles

[Kevin Krammer]

On Sunday, 2014-02-23, 19:53:34, Martin Koller wrote:
> On Wednesday 19 February 2014 23:13:16 Kevin Krammer wrote:
> > On Wednesday, 2014-02-19, 22:06:06, Martin Koller wrote:
> > > On Wednesday 19 February 2014 17:31:13 Daniel Vrátil wrote:

> > > 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).

Well, errors are shown. At least I occasionally see one :)

> 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(...)")

I think the status() ones are currently not displayed but I have definitely 
seen cancelTask() ones.

So doing the status() thing might be save.

> > 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.

True. I was mostly thinking internal use, as Dan already wrote.
Basically so that, e.g. the base code can detect a failed connection attempt.
A Disconnected -> Disconnected "transition" doesn't sound that obvious.

> 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.

Right.

> And "NotConfigured" as Status is even worse. How can a resource ever be set
> "enabled" (online) when it was not configured ?

One of the things that were added later on when the need arose to detect 
resources that are there but not capable of functioning yet.
I don't remember though what triggered this need.

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-pim/attachments/20140301/5eedb482/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/