[Tickets #12605] Re: AS: Fix loss of PINGABLE flag

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12605
------------------------------------------------------------------------------
  Ticket             | 12605
  Updated By         | Thomas Jarosch <thomas.jarosch at intra2net.com>
  Summary            | AS: Fix loss of PINGABLE flag
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 2. Medium
  Milestone          |
  Patch              | 1
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Thomas Jarosch <thomas.jarosch at intra2net.com> (2013-08-23 15:58) wrote:

>> when the PIM requests a PING for a folder it didn't sync yet (=fresh
>> account),
>> the synckey will be empty and we won't set the collection as pingable.
>
> It shouldn't do this. A SYNC is a MUST before a PING.
>
>> If I'm not mistaken, we need an enum (=state machine) here:
>> 0 => not pingable
>> 1 => PIM wants ping but we don't have a synckey
>> 2 => pingable
>>
>> what do you think?
>
> We couldn't PING the folder anyway, even if it was marked as  
> PINGABLE until we have a valid SYNC performed on the collection, so  
> I'm not sure what value keeping track of the client's error in  
> sending the PING for collection would be.  I'll have to reread the  
> specs again to be sure I'm not missing something here, but I'm 99%  
> positive that this is broken client behavior.

We don't have to ping the folder if we don't have a synckey yet
(as you mentioned we can't send changes anyway), we just skip it until  
we have a synckey.

We could modify the "<Ping>" handling to mark all wanted folders
as pingable unconditionally and remove the "pingable" flag
from any folder that is not in the list.

If the PIM sends "<Ping>" without a folder list, we check
which pingable folders have a sync key and skip those without one.
I don't think the new strategy costs any extra performance than the  
current one.


The broken client in question is iOS 4, I'll have to retest how iOS 6 behaves.
Though it's not that uncommon to configure an account, may be open the
INBOX to see if it's initially working and then go back to the settings menu
and select a bunch of folders than should be pushed through.


Looking through the code how updatePingable() works, I think
it sets the 'pingable' flag for any folder in the collection with a  
'synckey' field?!
Isn't that NOT the desired behavior?

That would explain why I see getServerChanges() calls
for any folder I've accessed on the PIM, even though
I just set the push mode for three of them...