syncitems — Returns a list (or part of a list) of all the items (journal entries, to-do items, comments) that have been created or updated on LiveJournal since you last downloaded them. Note that the items themselves are not returned --- only the item type and the item number. After you get this you have to go fetch the items using another protocol mode. For journal entries (type "L"), use the getevents mode with a selecttype of "syncitems".
Returns a list (or part of a list) of all the items (journal entries, to-do items, comments) that have been created or updated on LiveJournal since you last downloaded them. Note that the items themselves are not returned --- only the item type and the item number. After you get this you have to go fetch the items using another protocol mode. For journal entries (type "L"), use the getevents mode with a selecttype of "syncitems".
The protocol request mode: syncitems
Username. Leading and trailing whitespace is ignored, as is case.
The authentication method used for this request. Default is 'clear', for plain-text authentication. 'cookie' or any of the challenge / response methods are also acceptable.
DEPRECATED. Password in plain-text. For the default authentication method, either this needs to be sent, or hpassword.
DEPRECATED. Alternative to plain-text password. Password as an MD5 hex digest. Not perfectly secure, but defeats the most simple of network sniffers.
If using challenge / response authentication, this should be the challenge that was generated for your client.
If using challenge / response authentication, this should be the response hash you generate based on the challenge's formula.
(Optional) Protocol version supported by the client; assumed to be 0 if not specified. See Chapter 11: Protocol Versions for details on the protocol version.
(Optional) The date you last downloaded synced, in "yyyy-mm-dd hh:mm:ss" format. Note: do not make this date up from the client's local computer... send the date from this mode's response of the newest item you have saved on disk.
OK on success or FAIL when there's an error. When there's an error, see errmsg for the error text. The absence of this variable should also be considered an error.
The error message if success was FAIL, not present if OK. If the success variable isn't present, this variable most likely won't be either (in the case of a server error), and clients should just report "Server Error, try again later.".
The total number of items that have been updated since the time specified.
The number of items that are contained in this response (numbered started at 1). If sync_count is equal to sync_total, then you can stop your sync after you complete fetching every item in this response.
The nth item, in the form "Type-Number". Type can be one of "L" for log entries (journal entries), "C" for comments (not implemented), "T" for to-do items (not implemented), or many other things presumably. If your client doesn't know how to fetch an item of a certain type, just ignore them. A new version of your client could later see that it has never downloaded anything of type "T" and go back and fetch everything of that type from the beginning.
Either "create" or "update". This field isn't too useful, but you may want to make your client verbose and tell the user what it's doing. For example, "Downloading entry 5 of 17: Updated".
The server time (in the form "yyyy-mm-dd hh:mm:ss") that this creation or update took place. Remember in your local store the most recent for each item type ("L", "T", "C", etc...). This is what you send in subsequent requests in lastsync.