February 14th, 2002

hulk, strong, party
  • revjim

syncitems....

Since Journals have been clustered, the itemids representing each entry have be changed. This means that the "backups" people may have been making of their journals now have incorrect itemids associated with the older entries. This means that clients should resync ALL their entries. It would be REAL nice if the syncitems mode would FORCE clients to do this by telling the clients that ALL the users old entries have been deleted and that that there are MANY new entries to sync on the next run. Since this is A LOT of work on the server side to code and it effects so few users, it may not be worth the time. So... in that case, it would be best for users of "syncitems" to delete their entry stores, and resync everything again. If they, in the future, should they edit or delete an entry that was synced before clustering, resyncing will cause the client to create a second entry with the modifications, instead of altering the original, or, in the case of a delete, the entry will not actually be deleted.
Hair Cut

Protocol Issue

mode: postevent
response: itemid

Once an event has been posted successfully, itemid is set to the unique number which is assigned to the post. Ever since clustering, although this is still true, there is no way of knowing whether the itemid is a part of a clustered journal or not. Thus if a client uses the itemid to build a URL to link back to that entry, should there be another response that says whether a journal is clustered? Or should we assume that if the itemid > 20000000 that it's not clustered yet?

I know that this won't be an issue once all journals are clustered as non-clustering will be obsolete, I just thought this should be mentioned.

:-)
  • Current Mood
    geeky