?

Log in

No account? Create an account
problems with lastsync - LiveJournal Client Discussions — LiveJournal [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

lj_clients

[fg]
halo,

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?
linkReply

Comments:
[User Picture]From: fg
2004-04-04 03:35 pm (UTC)
ok, fair enough. that makes sense. i checked the action for that sync item, and it shows it as "update".

however,

following the logic in the algorithm you described a few posts down (and following evan's similar logic in the algorithm he posted as a reply, from logjam, won't deleted posts cause you to loop forever? (you never get that itemid, hence you never mark it as downloaded)

if the syncitem was marked as "delete" instead of update, i think this could be dealt with. kind of makes sense that way.

am i being obtuse?
(Reply) (Parent) (Thread)
[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.

hmmm.
(Reply) (Parent) (Thread)