[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         | Michael Rubinsky <mrubinsk at horde.org>
  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
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2013-08-27 23:02) wrote:


> When the ping is processed we don't have the folder in the sync cache yet.
> We added the collection in memory to "this->_collections" but it's not
> part of the collection we get from the syncCache.

Heh. Of course, now that you mention it, that seems completely  
obvious. If the collection was never synchronized, of course it won't  
be in the syncCache (unless the PING request was issued immediately  
after the first, syncKey == 0,  SYNC for the collection.

OTOH, it looks like the part that was wrong then was faking the  
detected changes to force the SYNC, since that is essentially the only  
difference in the code path (the collection is still not marked as  
PINGABLE). So, iOS is doing the Wrong Thing (tm) in PINGING the  
collection, but doing the Right Thing (tm)  by not expecting the  
server to do anything with the request.  I guess it wouldn't hurt to  
explicitly iterate $this->_collections and look for empty synckeys as  
a separate step. There shouldn't be that many of them to cause any  
extra overhead.

> Later on everything is fine, the device sends a Sync
> for the folder and another Ping request.  Wild guess:
> Through the modified behavior (we don't tell the client there are changes),
> the device is behaving "correctly" now.

So, from your point of view, the ticket is resolved?