Comments below. Brian Smith wrote: > [snip] >> That said, however, once the initial sync is completed, >> subsequent incremental sync's are much more efficient if >> paging is not used (e.g. give me one feed document describing >> just the things that have changed over the last twelve hours, etc). > > On the other hand, if there were hundreds of entries updated in > the last 12 hours (e.g. a server upgrade which modifies the > representation of every entry, or whatever else WordPress users > do that causes every entry to appear updated), the client and the > server will probably both benefit from chunking that up. Especially, > on mobile phones, the larger the response, the less likely the service > provider's proxies will let it go through to the device. >
Either way, it's generally the same amount of data being transferred, only you have to deal with multiple requests and scanning through each page to detect which items have changed. Even with pipelining, that's less efficient than making a single request with a single response that you know for certain contains only items that have been modified. Regarding mobile devices: I may just be demonstrating my ignorance of mobile device development, but I'd be rather surprised to find a mobile device that would want to maintain a complete, persistent local snapshot of a collection. What I suspect would be most common is the device wanting only to maintain a limited listing of the 10-20 most recently updated posts -- something that can be achieved currently without feedsync. >> Again, this would work so long as the pages remain stable; >> however, I would very much like to see a comparison of how >> the two approaches compare in terms of performance / efficiency. > > Well, obviously paging is going to require more roundtrips if there > are multiple pages used for the sync. If the server decides to use > one page per resync then both approaches are equivalent. In fact, > disregarding snapshotting, my solution is the same as yours, except > in mine the server controls the values of the "since" and "until" > parameters, whereas in yours the client controls them, and mine allows > the server to break up the response into multiple (cacheable) pages. So long as the feeds contain only the entries that were modified within the specified period of time then yes, without paging the approaches are equivalent. In other words, I want to avoid having to scan through the entries to determine which entries have or have not changed since the last time I looked at the feed; instead, I want to know that when I'm syncing, ALL of the entries listed in that feed document have changed since the last time I sync'd. - James > > - Brian > >
