[Kde-pim] Akonadi Resource - setOnline troubles

[Martin Koller]

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:
> > > Disconnected
> > > Resource requires access to network, but no network is available.
> > > ResourceBase automatically moves between Disconnected and Connected
> > > states based on network availability reported by Solid. There is the same
> > > problem with data retrieval as in StayDisconnected.
> > > 
> > > TemporaryDisconnected ( == BackendNotAvailable? )
> > > Network is available,  but connection to server cannot be established (or
> > > maildir folder is not available because it's not mounted for instance).
> > > Resource sets itself to this state and will attempt to reach the backend
> > > periodically (ResourceBase will emit a "tryReconnect" signal in
> > > configurable intervals). Once it succeeds, it will switch itself back to
> > > Connected.
> > I'd say these are both the same.
> 
> 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"

> > Both are "TemporaryDisconnected" with automatic retry.
> 
> Hmm. Network not available doesn't require a retry, right? No point in trying 
> to open a connection until Solid reports network back online and that changes 
> the state.

Right. It needs a retry of the last action when the network is back online (when Solid
tells us it's there). I do not mean retry in a continuous way via timeout.

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

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

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

Back to my original problem: is there another way of telling the resource to "enable the change recorder"
than to switch it to "offline" ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                                   - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
_______________________________________________
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/