43 lines
3.1 KiB
XML
Executable File
43 lines
3.1 KiB
XML
Executable File
<method name="checkfriends">
|
|
<shortdes>
|
|
Checks to see if your friends list has been updated since a specified time.
|
|
</shortdes>
|
|
<des>
|
|
Mode that clients can use to poll the server to see if their friends list has been updated. This request is extremely quick, and is the preferred way for users to see when their friends list is updated, rather than pounding on reload in their browser, which is stressful on the serves.
|
|
</des>
|
|
<arguments><struct count="1">
|
|
|
|
&authInfo;
|
|
|
|
<key name="lastupdate" count="1"><scalar><des>
|
|
The time that this mode request returned last time you called it. If this is the first time you've ever called it (since your client has been running), leave this blank. It's strongly recommended that you do not remember this value across invocations of your client, as it's very likely your friends will update since the client was running so the notification is pointless... the user probably read his/her friends page already before starting the client.
|
|
</des></scalar></key>
|
|
|
|
<key name="mask" count="opt"><scalar><des>
|
|
The friend group(s) in which the client is checking for new entries, represented as a 32-bit unsigned int. Turn on any combination of bits 1-30 to check for entries by friends in the respective friend groups. Turn on bit 0, or leave the mask off entirely, to check for entries by any friends.
|
|
</des></scalar></key>
|
|
|
|
</struct></arguments>
|
|
|
|
<!--===================[ RETURN ]==============================-->
|
|
<returns><struct count="1">
|
|
|
|
<key name="new"><scalar><des>
|
|
This is what you should use to determine if there are new entries. Its value is "1" if there is new stuff, or "0" if there isn't. A few people requested that this return the number of new entries, but that's a lot more resource intensive, and this protocol mode is supposed to be very quick and painless. In the future we may add a "new_count" response value that says how many new items there are. Note that once this values becomes "1" and you alert the user, <emphasis>stop polling!</emphasis> It'd be pointless to have the client hitting the server all night while the user slept. Once the user acknowleges the notifcation (double-clicks the system tray or panel applet or whatnot), then resume your polling.
|
|
</des></scalar></key>
|
|
|
|
<key name="interval"><scalar><des>
|
|
How many seconds you <emphasis>must</emphasis> wait before polling the server again. If your client disobeys, this protocol will just return error messages saying "slow down, bad client!" instead of giving you the data you were trying to cheat to obtain. Note that this also means your client should have an option to disable polling for updates, since some users run multiple operating systems with multiple LiveJournal clients, and both would be fighting each other.
|
|
</des></scalar></key>
|
|
|
|
<key name="count" count="1"><scalar><des>
|
|
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.
|
|
</des></scalar></key>
|
|
|
|
<key name="total" count="1"><scalar><des>
|
|
The total number of items that have been updated since the time specified.
|
|
</des></scalar></key>
|
|
|
|
</struct></returns>
|
|
</method>
|