[Kde-pim] Making offline/online handling sane

[Kevin Krammer]

On Wednesday, 2012-12-05, Andras Mantia wrote:

>  first of all, I guess we are mostly on the same page now with your naming
> of Offline to StayDisconnected or DoNotUseNetwork. :)
> I kept using offline, as that was the term KMail used all the time for "do
> not access network". The meaning changed (got broader) only when Akonadi
> was introduced. But I don't mind changing the terms for Akonadi resources,
> although you should be aware that KMail still uses the offline term in its
> UI.

I think this is largely separate from any UI issue. The terms we use for the 
implementation need to be clear to developers of agents/resources, which terms 
we map to in the UI is something we would best discuss with the translators.

> >> I see no contradiction. Offline will not mean anymore the resource is
> >> not allowed to perform *any* work, it will mean it won't be allowed to
> >> perform network operations.
> > 
> > Again assuming Offline as StayDisconnected: isn't that independent of the
> > backend access mechanism? E.g. if the backend is accessed via Unix
> > socket?
> 
> With network access I mean anything that can cause network traffic. Think
> of using internet in roaming or paid per-data-volume transfer, so you want
> to limit your applications in not using the network and not cause extra
> traffic. Or the case Laurent mentioned: you work on two computers and you
> want to keep them in sync somehow, and to avoid conflicts you limit one of
> your computers to access the network, while the other is allowed to do.
> Very useful for POP3 sources.

Right. Hence my suggestion later on to have this as a separte flag/state.

> >> The reason this cannot be in ResourceBase or AgentBase is that we can't
> >> control what the resource does or not. We can either completely shut it
> >> down (like we do now) or not.
> > 
> > The resource handles that if it wants to (it can reimplement
> > doSetOnline). I think the problem is that this is not precise enough,
> > since we have currently multiple concepts applied to a single boolean.
> > 
> > Or do you want to make sure every resource handles the state changes, as
> > in making something pure virtual?
> 
> This is an implementation detail question. :) Indeed, we can add an extra
> pure virtual function (setNetworkUsageMode() or such),

We have a "needs network function" that is only called by networked resources.

> but that will be
> BIC, and I always forget if we need to keep BC in pimlibs or not (I guess
> we need).

We do. kdepimlibs is one of KDE's platform modules.

> So maybe the only way to do it now is to have a setter and
> getter for this boolean and trust the resources they comply to it. Not
> optimal, I know.
> 
> >> What I propose is to make the offline a flag
> >> that the resource can use to turn the network operations off, if it
> >> needs network. If you still want the current offline=turned off
> >> behavior, we can keep it, but call it the right way.
> > 
> > Well, offline means both things so we need replacement for both meanings.
> > (if we reuse offline for one of them I expect confusion).
> 
> That's the whole point, to not reuse it, but separate the one "offline"
> boolean into more than one, just as you point out later.

We have a setter: bit.ly/XFDDRd
I think it is called by all resources which usually need network.
Since we want to refine "needs network" to mean "needs non local network" we 
might have to handle that in different places (right now network resource call 
the setter in the constructors IIRC).

> > Of course not offline as in "cannot create a TCP connection", but it
> > could still not be able to reach its backend, e.g. removable volume
> > removed.
> 
> That is indeed true. But that is not a user indicated behavior, but a
> change in the backend reachability. That'd be like the IMAP resource
> turning itself off if it cannot log in to the server. That is what happens
> now (just to make the meaning of offline more confusing :) ).

We have two different things. One is the user denying access and one is not 
being able to access.
Not having an appropriate network interface is the same thing as removable 
media not being mounted, i.e. the detected variant, not the user decision.

> > Right. I think we will need it, user's don't want to get errors if the
> > network is not available, they expect software to detect that.
> 
> Sure. Actually mishandling of this case was the cause of a bug I fixed
> recently: you set KMail to offline mode (it set the resources to offline).
> You disconnected from the net and reconnected (eg. after suspend/resume).
> The resources realized there is network, and they happily switched
> themselves back to online mode, while KMail (and the user) asked them to
> stay disconnected. And your mail was downloaded when you didn't want to.
> This also suggest that the resource internal state regarding "can I use the
> network" should be different from the user's request about "should I use
> the network".

Right. Each such capability is basically associated with a permission.
I.e. "Am I able to" and "Am I allowed to" or more precisely "Do I think I 
would be able to" (only a connect attempt can tell you if you are) and "Am I 
not prohibited from"

E.g. for an IMAP resource with remote server that would map into "Does Solid 
tell me there is networking available" and "Did the user not set 
DoNotUseNetwork".

> ah, sorry. Indeed, you're right. A complete sync with full payload caching
> (disconnected mode), should deliver the full payload regardless of the
> network status or even regardless if the resource works at all.
> If only the envelope is cached, we have several cases if the body is
> requested:
> - resource turned off: error that the resource is off
> - resource set to "StayDisconnected" state: error that the content cannot
> be delivered because network access is not allowed
> - resource is on, it is allowed to access the network, but there is a
> network error (e.g it cannot log in, server failure, etc): you said the
> user shouldn't see such errors. I wonder if it is really how it should
> behave. Probably the resource should do some automatic retries, but give
> up and inform the user after a while.

Right. It is currently up to the resource whether it wants to retry. At some 
point it will fail the requested operation and Akonadi will relay the given 
error.

> >> If you still want that, we can keep, but I will/want to rename the
> >> feature to "Turned off" instead of "Offline" and make "Offline" do what
> >> it should do: work, but don't touch the network.
> > 
> > As written above we'll need several more user switchable states.
> > 
> > Right now we have
> > - TurnedOff (if we want that)
> > - DoNotAccessBackend
> > - DoNotUseNetwork
> 
> What would be the difference between DoNotAccessBackend and
> DoNotUseNetwork? Or you mean like DoNotAccessBackend would mean the IMAP
> would not be able to access also local servers (on the same machine),
> while DoNotUseNetwork would disable access only to remote servers?
> Although not that bad idea, it might make things more complicated inside
> the resources. Of course, they are free to treat both the same way as a
> start.

I added the DoNotUseNetwork since I had the impression that this is what you 
explicitly wanted to have, i.e. a way to tell resources not to cause network 
traffic.

For a network resource with remote server that would be the same thing, for a 
network resource with local server it would not.

But I was mostly thinking about agents which usually often don't have a 
backend but could make use network, e.g. if a spam filter agent uses network to 
do a lookup in an online blacklist or something like that.

> > Due to user expectations of software not attempting network access if
> > there is not network available we might need a state that reflects the
> > deteced unavailability of network, e.g. HasNoNetwork, and one that
> > reflects detected unavailability of backend, e.g. HasNoBackend
> > detected as opposed to encountered during operation attempt. The latter
> > would result in an error and "broken" resource state.
> 
> I agree with the need of such state, but the question about the distinction
> of the two is still there. If there is no network, on a network based
> resource that implies HasNoBackend. Network state in itself can easily be
> queried from Solid, so we might just keep the HasNoBackend state, no?

In the HasNoXYZ case, i.e. when we detect things (rather then being told by 
the user), just having HasNoBackend could be sufficient.

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/20121209/4dc83a69/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/