ljprotocol.pl patch -- getfriendposts client protocol addition
Hey everybody!
I've spent the day working on a patch to extend the client functionality another big step. Notably, the below patch enables clients to access the
Mode parameters:
Return values are like this:
Ahh! Lots of data, eh? Okay. This has been tested on my local server and is currently running there if anyone wants to play with it. I've tested it with communities and secured entries. I've tested the skip mechanism and specifying the number of items to return. It should work with clustering because the functions it calls are cluster-aware functions.
Comments? Questions? Suggestions? Y'know where to reach me.
Click here for the patch itself.
I've spent the day working on a patch to extend the client functionality another big step. Notably, the below patch enables clients to access the
getfriendposts mode which returns, basically, the events on your friends page. It fully supports specifying how many items to return and if you want to skip items or not. Most of the code is pulled from ljviews.pl's friends view generator, so it has the same sort of checks and balances to make sure they're not pulling everything that's ever happened on the friends page. Maximum items returns is 50. There are also options to enable you to skip returning the text of the events and the logprops, individually configurable.Mode parameters:
mode | getfriendposts |
user | username to view from |
password/hpassword | password or MD5 hashed password |
showitems | items to return |
itemskip | number of items to skip |
getprops | 1==return logprops, 0==don't |
gettext | 1==return text, 0==don't |
Return values are like this:
success | OK/FAIL |
errmsg | error message of success==FAIL |
event_count | number of events returned |
skip | number of events skipped |
event_X_subject | subject of event #X |
event_X_text | text of event #X if gettext==1 |
event_X_date | timestamp of event |
event_X_poster | the actual person who posted this event |
event_X_friend | the journal the event was posted in (community name) |
event_X_itemid | [j]itemid of this event |
event_X_replycount | number of comments on this entry |
event_X_prop_count | number of properties on this event |
event_X_prop_Y_name | name of property |
event_X_prop_Y_data | contents of property |
Ahh! Lots of data, eh? Okay. This has been tested on my local server and is currently running there if anyone wants to play with it. I've tested it with communities and secured entries. I've tested the skip mechanism and specifying the number of items to return. It should work with clustering because the functions it calls are cluster-aware functions.
Comments? Questions? Suggestions? Y'know where to reach me.
Click here for the patch itself.