[Kde-pim] Akonadi Resource - setOnline troubles

[Kevin Krammer]

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.

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

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

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/20140219/8a32e88f/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/