Log in

No account? Create an account
LiveJournal Client Discussions [entries|archive|friends|userinfo]
LiveJournal Client Discussions

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

problems with lastsync [Apr. 4th, 2004|01:47 am]
LiveJournal Client Discussions



i've implemented a client that uses the syncitems/lastsync routines. i read evan's code and wrote a similar implementation, popping off syncitems as they were downloaded, and looping until syncitems is empty.

my algorithm was in stuck in an infinite loop, and here i was pulling my hair out for hours thinking 'Perhaps the client is broken?'.

calling syncitems first, the server is returning an array of items, and one item in particular has the itemid 441. (testing this on my own journal)

then, following getevents through its course, the final result set has NO itemid of 441. furthermore, calling getevents with selecttype of "one" and "itemid" of 441 returns an empty result set.

if this item doesn't exist, why in the world is syncitems returning it to start with? is this a bug? what's going on?

[User Picture]From: marksmith
2004-04-04 04:36 pm (UTC)
find the oldest "time" in this hash for items that have downloaded == 0
mark THIS item as downloaded (so we don't use the same time twice and loop forever)

You'll never loop if you follow my instructions to the letter. :) Whenever you use something as the lastsync time, you mark it as downloaded. That way, if there's a problem of any sort, the worst case scenario is that you send one request per entry you have from syncitems, which is bad, but still better than looping forever.

And if the item is marked as updated, and you don't get it back from getevents, you can assume it's deleted.
(Reply) (Parent) (Thread)
[User Picture]From: fg
2004-04-04 04:52 pm (UTC)
aha! very sneaky. thanks for clearing that up.
(Reply) (Parent) (Thread)
[User Picture]From: fg
2004-04-04 05:08 pm (UTC)
if a user has a habit of deleting a lot of their entries, syncitems has the potential to be very slow and very painful on the server. that's one extra getevents call for EVERY entry that it can't find.

i came up with a more optimistic algorithm, except it will also loop forever in the rare event that a user deletes 100 entries in a swath.

if syncitems differentiated between "update" and "delete", you could write a much more elegant, less taxing algorithm.

(Reply) (Parent) (Thread)