October 29th, 2002

Replacing syncitems

I want to replace the syncitems tables/protocol mode with something else.

Syncitems takes a lot of disk space and nobody uses it because no clients exist because it's too complicated.

I propose two new logprops:


Both are opaque revision identifiers that backup clients can use to decide if they already have the data cached locally. On an editevent, we just update the postrevstring. It could be anything... incrementing number, unixtime, or md5 of all data. I'm leaning towards md5 there.

Comrevstring would be updated whenever an event took place that edited comments on a post... new comment, unscreened, deleted, etc. The format of this would probably be "unixtime-remoteid" to avoid needing to read beforehand and do locking.

But regardless of their formats, all backup clients would need to do is:

-- fetch all post IDs & rev strings (one request)
-- for each post with a new postrevstring, fetch it. (could make new selectmode for getevents to let people retrieve multiple at once)
-- for each post with a new comment string, retrieve all comment meta-data on post. (new API mode).
-- retrieve comment text for all not already cached (comments can't be edited, so no revstring needed there)

I have an ActiveState Perl Developer Kit license now, so I can compile the Perl backup client for Windows.

I'm also about 95% done porting S2 from Java to Perl, so the backup client can later include the S2 compiler and runtime to generate client-side HTML from the backup archives.

But syncitems should go. Nobody's using it anyway, right?

  • timwi

Misdated entries

Is there any particular reason why we're not allowing users to post an entry with datetime X if they have an entry with datetime Y > X that does not have the backdate property set?

I can see that users should be warned that their entries will be out of order, but I don't see why it's an error and, like, completely not allowed.

It seems to confuse people enough so they open support requests about it.