how does it know what you have tho?

Reply to this note

Please Login to reply.

Discussion

1. In the beginning the server sends you a list of fingerprints of id ranges.

2. You check if your local fingerprints for the same ranges match.

3. When they match, you say that part matches; when they don't match, you look inside the range to see what you have.

4. If you have few ids or none for that range, you send the ids you have -- then the server will send back the ids it has; if you have way too many ids inside that range, you split the range into multiple ranges and send a fingerprint of each.

5. Repeat the process for all ranges until have narrowed them enough for you to get a list of the ids you don't have from the server -- as well as the ids you have that the server doesn't.

Something like that, I may have gotten details wrong.

that sounds right but this range thing is a very fuzzy concept in 2^256 finite field

Oh, yes, the range is based on the created_at timestamps.

this is why i think a query type that only returns the event IDs would be useful as a building block for more sophisticated sync protocols, especially if it was using more compact binary data, or at least base64