[Kde-pim] Making offline/online handling sane

Wed Dec 5 11:16:53 GMT 2012

Hey Andras,

I completely agree with your analysis, and funny enough, my
interpretation of the offline state was exactly the other way round; the
offline state disables the agent so it shouldn't do any work.

As you suggested we should separate those states:

* offline: a flag purely for the resource to stop using the network
(because it's not there or because I don't want the resource to use it).
So not used in resourcebase at all, apart from the setter and getter.
* disabled: the current resourcebase use of offline, the agent should
stop doing *any* work. So this state isn't related to network operations
at all, it just tells the resource to stop.

I'm also not sure if we really need the disabled state, but it's IMO a
nice switch for developers (so if it's only available from
akonadiconsole that's enough IMO). Also it might be useful as more
granular emergency switch if something goes awry with one resource,
without the need to disable all of akonadi.

So if it isn't too much work, I'd like to see the disabled state as
well.

Thanks for looking into it, this really needs a fix.

Cheers,
Christian

On Sat, Dec 1, 2012, at 05:48 PM, Andras Mantia wrote:
> Hi,
> 
>  I've been sturggling a lot whenever I travel with the fact that I cannot 
> read my *offline* imap mail. Friday I run into it again and spent almost
> all 
> my flight time to identify and fix the problem. What I discovered is not 
> good.
> 
> The problem
> -----------
>   The visible problem is that if a resource is offline, and there is a 
> request to it to deliver an item, you get an error:
> "Cannot fetch item in offline mode." 
> 
> The cause
> ---------
>   For the above, the cause is pretty simple:
>    if ( !isOnline() ) {
>      const QString errorMsg = i18nc( "@info", "Cannot fetch item in
>      offline 
> mode." );
>      emit error( errorMsg );
>      return errorMsg;
>    }
> in ResourceBase::requestItemDeliveryV2. 
> Sounds simple and reasonable at the first read, but here is a question:
> why 
> do we have it in the ResourceBase? 
> 
> The real problem
> ----------------
> 
> The answer to the above question is: because we don't know what
> "isOnline" 
> means for a resource. There is a weird mix of its meaning in the Akonadi 
> libraries and resources. Does it mean that the resource is turned off?
> Does 
> it mean that the resource is not allowed to do network operations? Does
> it 
> mean a mix of the two or something else?
> Well, the problem is that right now it is a mix. From the above it means 
> that Akonadi should not even *try* to get anything from a resoruce that
> is 
> offline, as it will get an error, so it means "offline resource is turned 
> off resource". But a resoruce is automatically turned offline if there is
> no 
> network. That means a resource is offline when there is no network. And
> this 
> is *generic*, the code is in AgentBase that turns them offline.
> 
> What the above means: no network, resource goes offline, if akonadi wants
> to 
> get something from it, you get the error.
> 
> Even more: if a resource is offline, the task scheduler inside the
> resource 
> does nothing. Task processing is shut down (see  void 
> ResourceScheduler::scheduleNext() ). This means not even a local resource 
> works on offline mode: no task are processed.
> 
> The suggested solution
> ----------------------
> Hereby I suggest to bound the "online" state to the network operations. 
> Online means a resource is *allowed* to perform network operations.
> Offline 
> means a resource is *not allowed* to perform network operations. The
> Akonadi 
> libraries (and here I mean AgentBase and ResourceBase) don't deal with 
> online/offline state, the most they do is to signal the network state, 
> although this would just replicate a Solid signal, so no real need for
> that 
> either. Akonadi *should not* care about what the resources do or allowed
> to 
> do.
> Online/Offline handling will be moved to the resources. If a resource 
> doesn't work on the network, it just ignores it: it cannot be set
> offline. 
> If it works on a network, if setOnline(false) is called, it must shut
> down 
> all network connections and should not perform any network operation
> until 
> setOnline(true) is called.
>  POP3 seems to do the right things, IMAP doesn't.
> If it wants, it can give back items in another way (think of local cache
> per 
> resource).
> 
> The questionmarks
> -----------------
> 
> I couldn't do a complete analysis of the whole code yet, I run out of
> flight 
> time. :) And there are some questionmarks in my mind:
> - why can you read offline imap content if you set KMail to offline (but
> you 
> cannot if you have no network): here I just have a guess: if the IMAP 
> resource cannot connect to the server, it sets itself to offline mode 
> (another confusion, as offline in this context might mean "broken"). If
> it 
> is in that state, it starts to report errors back to the Akonadi server. 
> My suspition is that "KMail in Offline mode", but with working connection 
> doesn't set the imap resource completely offline and it performs some 
> operations instead of reporting back errors (like cannot connect to the
> imap 
> server).
> - why does Akonadi asks at all for items on a disconnected IMAP account, 
> when everything should be in cache? Note that my wondering is only for
> the 
> items. There is anyway the problem I said above, as IMAP sync folders on 
> click, while it can't do it in offline mode. You end up with some sync
> task 
> scheduled...
> - how many resources would be affected, who relied on the current offline 
> interpration?
> 
> Anyway, I'd not mind if somebody would try to reproduce what I see to 
> confirm it. How to do it?
> - set up a maildir and a disconnected IMAP account
> - sync them, especially the disconnected IMAP so you are sure mail
> content 
> is downloaded
> - File>Work Offline in KMail: everything should work fine, you can switch 
> between folder and read mail content
> - in akonadiconsole set the maildir resource offline and try to read
> mails 
> (read those that you haven't read lately, so they are not in the cache)
> - unplug any network cable, shut down any wireless acount, if possible 
> disable the wireless completely. Now try to read mail on the IMAP account 
> and switch folders. Alternatively restart Akonadi/KMail after you
> disabled 
> the network.
> 
> Tell me how it works.
> 
> If you agree with the above approach, I volunteer to come up a solution 
> inside the akonadi libs (which will be easy, like removing code mangling 
> offline and leave there only the interfaces to set a resource 
> offline/online) and check the imap/pop3/mail dispatcher resources that
> they 
> perform well and do what you should.
> 
> The above suggestion removes the feature of turning off a resource. In
> order 
> to have that, we would need to introduce a new state for resources, but
> I'm 
> not sure we need it at all.
> 
> Andras
> _______________________________________________
> 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/
_______________________________________________
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/