[Kde-pim] Akonadi Resource - setOnline troubles

[Martin Koller]

ping.

I really like to solve that problem.
Any comments or an answer ?

On Sunday 23 February 2014 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:
> > > > 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/