The protocol request mode: getevents

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 27, Protocol Versions for details on the protocol version.

(Optional) An optional value that if greater than or equal to 4, truncates the length of the returned events (after being decoded) to the value specified. Entries less than or equal to this length are left untouched. Values greater than this length are truncated to the specified length minus 3, and then have "..." appended to them, bringing the total length back up to what you specified. This is good for populating list boxes where only the beginning of the entry is important, and you'll double-click it to bring up the full entry.

If this setting is set to true (1), then no subjects are returned, and the events are actually subjects if they exist, or if not, then they're the real events. This is useful when clients display history and need to give the user something to double-click. The subject is shorter and often more informative, so it'd be best to download only this.

If this setting is set to true (1), then no meta-data properties are returned.

Determines how you want to specify what part of the journal to download. Valid values are day to download one entire day, lastn to get the most recent n entries (where n is specified in the howmany field), one to download just one specific entry, or syncitems to get some number of items (which the server decides) that have changed since a given time (specified in the lastsync parameter>). Not that because the server decides what items to send, you may or may not be getting everything that's changed. You should use the syncitems selecttype in conjunction with the syncitems protocol mode.

For a selecttype of syncitems, the date (in "yyyy-mm-dd hh:mm:ss" format) that you want to get updates since.

For a selecttype of day, the 4-digit year of events you want to retrieve.

For a selecttype of day, the 1- or 2-digit month of events you want to retrieve.

For a selecttype of day, the 1- or 2-digit day of the month of events you want to retrieve.

For a selecttype of lastn, how many entries to get. Defaults to 20. Maximum is 50.

(Optional) For a selecttype of lastn, you can optionally include this variable and restrict all entries returned to be before the date you specify, which must be of the form yyyy-mm-dd hh:mm:ss.

For a selecttype of one, the journal entry's unique ItemID for which you want to retrieve. Or, to retrieve the most recent entry, use the value -1. Using -1 has the added effect that the data is retrieved from the master database instead of a replicated slave. Clients with an "Edit last entry" feature might want to send -1, to make sure the data that comes back up is accurate, in case a slave database is a few seconds behind in replication.

The desired type of line-endings you'd like LiveJournal to return. Possible values are unix (0x0A (\n)), pc (0x0D0A (\r\n), the default), mac (0x0D (\r)), space (newlines become spaces), or dots (newlines become " ... "). The PC format was chosen as a default because it contains both Unix and Mac line endings in it, so if a client doesn't pick a line ending format, the worst case scenario is there are some ugly characters in the client's textbox beside the real newlines.

(Optional) If getting the history of a shared journal, include this key and the username you wish to get the history of. By default, you load the history of "user" as specified above.

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 is not present, this variable most likely will not be either (in the case of a server error), and clients should just report "Server Error, try again later.".

The number of events being returned. The records returned are number from 1 to events_count.

The unique integer ItemID of the nth item being returned.

The time the user posted (or said they posted, rather, since users can back-date posts) the nth item being returned.

The nth event text itself. This value is first truncated if the truncate variable is set, and then it is URL-encoded (alphanumerics stay the same, weird symbols to %hh, and spaces to + signs, just like URLs or post request). This allows posts with line breaks to come back on one line.

If this variable is not returned, then the security of the post is public, otherwise this value will be private or usemask.

If security is usemask then this is defined with the 32-bit unsigned int bit-mask of who is allowed to access this post.

The subject of the journal entry. This won't be returned if "prefersubjects" is set, instead the subjects will show up as the events.

If the poster of this event is different from the user value sent above, then this key will be included and will specify the username of the poster of this event. If this key is not present, then it is safe to assume that the poster of this event is none other than user.

The authentication number generated for this entry. It can be used by the client to generate URLs, but that is not recommended. (See the returned 'url' element if you want to link to a post.)

The permanent link address to this post. This is an opaque string--you should store it as is. While it will generally follow a predictable pattern, there is no guarantee of any particular format for these, and it may change in the future.

The number of event properties being returned (meta-data about journal entries). Note that this will not even be returned if you set noprops to true.

The ItemID of the journal entry that this meta-data is attached to.

The character string (alphanumerics and underscore only) of the meta-data property name.

The value of the nth meta-data property.