The protocol request mode: editevent

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.

The unique ItemID of the item being modified or deleted.

The revised event/log text the user is submitting. Or, to delete an entry, just send no text at all. Carriage returns are okay (0x0A, 0x0A0D, or 0x0D0A), although 0x0D are removed internally to make everything into Unix-style line-endings (just \ns). Posts may also contain HTML, but be aware that the LiveJournal server converts newlines to HTML <BR>s when displaying them, so your client should not try to insert these itself.

Specifies the type of line-endings you're using. Possible values are unix (0x0A (\n)), pc (0x0D0A (\r\n)), or mac (0x0D (\r)). The default is not-Mac. Internally, LiveJournal stores all text as Unix-formatted text, and it does the conversion by removing all \r characters. If you're sending a multi-line event on Mac, you have to be sure and send a lineendings value of mac or your line endings will be removed. PC and Unix clients can ignore this setting, or you can send it. It may be used for something more in the future.

The subject for this post. Limited to 255 characters. No newlines.

(Optional) Specifies who can read this post. Valid values are public (default), private and usemask. When value is usemask, viewability is controlled by the allowmask.

Relevant when security is usemask. A 32-bit unsigned integer representing which of the user's groups of friends are allowed to view this post. Turn bit 0 on to allow any defined friend to read it. Otherwise, turn bit 1-30 on for every friend group that should be allowed to read it. Bit 31 is reserved.

If modifying only, the 4-digit year of the event (from the user's local timezone).

If modifying only, the 1- or 2-digit month of the event (from the user's local timezone).

If modifying only, the 1- or 2-digit day of the month of the event (from the user's local timezone).

If modifying only, the 1- or 2-digit hour from 0 to 23 of the event (from the user's local timezone).

If modifying only, the 1- or 2-digit minute of the event (from the user's local timezone).

Set an arbitrary (but restricted) meta-data property to this log item. If a key is sent, but the value is blank or zero (0), then the value of the given name is deleted from this item's property list. See Chapter 30, Journal Item Meta-data for more information.

(Optional) If editing a shared journal entry, include this key and the username you wish to edit the entry in. By default, you edit the entry as if it were in user "user"'s journal, 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 unique number the server assigned to this post.

The authentication number 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.