Twittering Trois

The TwitterBox is now present for your delectation on SLExchange and SLBoutique (the latter was giving me gyp last night, but seems to be behaving itself properly today).

As always, the latest versions of everything are available from my main TwitterBox page.

I have also now posted the source code for my PHP Intermediary Server Thing:

twitter-control-0.1.phps

This will not I expect be of interest to the casual Twitterer, but if you were wondering precisely what it was that the Thing did, well, do go ahead and read,and it may enlighten you to at least some small degree. There are a number of comments in the code, but, in short, it reads in the contents of the POST that is sent by the TwitterBox to it, which should be of the form

user email password action status

then evaluates the "action" parameter. There is a generic function to send a request to Twitter using curl, which returns the JSON data that it receives parsed into an array. (I wish more online services would agree to return data in the JSON format.)

Notes On The Process Of Obtaining The Owner's Proper Twitter Identity

The script makes it easier for users by only requiring them to enter their email address, which Twitter requires for the login procedure. Knowing the Screen Name of the owner is very handy for the TwitterBox, though, and in future I hope to use the ID number as well for nefarious and disgraceful purposes.

The TwitterBox gets round this by exploiting the two following facts:

1. Upon an update, Twitter sends back information regarding the last post made by the user, including username and user ID number;
2. Twitter will not post an empty update, but will still send information back.

Therefore, when it receives a "get id" action, the control script tries to make a blank update, which does nothing except returns information about the last post made. The script then takes the user's screen name and ID number and sends them back to the TwitterBox, which remembers them. Thinking about it now, I suspect that if the person has actually not made any tweets at all, this may not work. Hmm.

Notes On The Process Of Updating (or "Twittering")

As mentioned above, updating with either a blank or real entry returns information on the last post, including the time that it was created. The control script checks this - if it is before the time that it sent the request, it assumes that there was a failure to post and says so. Otherwise it says "OK".

Notes On The Process Of Checking For Tweets

When checking for recent updates, the script pulls together all of the tweets that it receives into the format:

screen_name text relative_created_at (this is the "about 4 hours ago" part) created_at (converted into UNIX timestamp format)

up to a limit of 1500 characters, which is about all that LSL will accept as the body. (The http_request event will allegedly accept 2049 bytes, but the header seems to take up a lot of this.) Note that it will not include a partial tweet if the length goes over the limit. It then sends the compiled tweets back to the TwitterBox. Actually, even restricting the number of tweets sent to 1500 characters, one still does get a satisfactory number of tweets.

If you read the LSL script for the TwitterBox itself, and you understand LSL of course, you will see that it is the box itself which actually decides which tweets to announce, if any, filtering them on the criteria "must not be posted by the owner's screen name" and "must be after the last tweet that I announced". The PHP script does not store any screen names or requests or any such thing, and it would have to make two requests to Twitter to be able to filter on screen name, which would be an extravagance. The TwitterBox itself is quite capable of doing this.

I actually find the way that the TwitterBox operates when displaying updates more convenient than using an External Instant Messaging Client, as the latter won't tell one what nonsense one's twittering friends have been blithering whilst one has been away - whereas upon entering SL now, I am immediately (or at least quickly) brought up to speed with the latest trivialities. Hah! What say you to that, Corporate IM Giants? Stop blubbering, Yahoo, it really is unseemly, stiff upper lip chaps. Things For The Future

The next version of the TwitterBox will hopefully possess a few new features:

• option to automatically post a SLurl for the user's location after every tweet (in tinyurl format, of course, SLurls can take up the whole of the tweet by themselves);
• automatic notification of other TwitterBox users in the vicinity, and the option to add them to one's friend list (this one might cause a little difficulty in practice, though I have a few ideas, and is probably going to be entirely useless anyway, so is the least likely to happen);
• an easier method of entering the username and password and generally configuring the TwitterBox;
• changing the sound and adding a more visual alert;
• the option of automatic updates on certain events (e.g. an automatic "has logged in" tweet on entering SL);
• anything else that isn't too difficult.

Do bear in mind that all of these things are "coming very soon/in the next update" in the Linden Lab sense i.e. may or may not appear at all.