« Free video streaming | Main | A FRBR-based model for Musical Recordings and Scores »

October 19, 2007

Second Friends update

I've been trying to do a bit of work on my Second Friends Facebook application over the last few days.

Firstly, I had to do some running repairs because of performance issues.  There's an important lesson here.  When you build a Facebook application, run it on a server that is pretty resilient and code it efficiently.  If your app is successful, then the back-end code is going to get hit fairly hard.  It's worth remembering that Facebook only waits around for about 5 seconds for your back-end application code to respond before giving out the standard "Facebook has hit a problem" kind of error message.  My initial attempts at coding the logic to work out who is friends with who were horribly inefficient - they worked when Second Friends only had 10 or so registered users.  But with well over 300 active users things were starting to creak at the seams and some of my scripts were taking well over 5 seconds to respond :-(

All fixed now I think.

Interestingly, the Facebook stats for Second Friends indicate that it has 814 users (to date), though only 322 of those have gone into Second Life to obtain their secret registration key from the Second Friends kiosk on Eduserv Island.  I don't quite understand why there is such a big difference in those two numbers! :-(  I have a nagging worry that there is some problem that is preventing people from signing up properly, though the fact that over 300 people have managed it successfully gives me some hope.

Sfstatusupdater Secondly, I wanted to improve the functionality.  I have several ideas for additions that I hope to come back to over the coming weeks.  My first attempt is to introduce a Second Friends 'status' - a place for your avatar to record their current state of mind or activity, as per the normal Facebook status.  I've made available a very simple Second Friends status updater, an object that tracks whether you are in-world or not and updates your Second Friends status accordingly.  It's not much, but it is functional.  You can get one from the box next to the Second Friends kiosk on Eduserv Island.

More importantly the API for your Second Friends status is open.  Look at the updater script to see how it works and feel free to build your own version.  Why not build a HUD or wrist-band that you can chat your Second Friends status to?  I plan to offer a wrist-band shortly, but if someone beats me to it I'd be very happy.  There is no documentation for the API, but it is very simple.  To update your status, simply make an HTTP GET request to:

http://artfossett.net/facebook/secondfriends/setstatus.php

setting the following attributes:

  • avname (e.g. avname=Art%20Fossett)
  • secretkey (e.g. secretkey=1234)
  • status(e.g. status=mooching%20around%20on%20Eduserv%20Island)

Remember that your status will be presented (on your Facebook profile) using the form "Art is ...".

Finally, it is also worth noting that there is a new kid on the block in this space - Second Life Link - a very similar Facebook application.  I guess others may also be on their way.  I suppose this is inevitable.  Alja Sulčič provides a nice overview of both applications in her blog.

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8345203ba69e200e5508632068834

Listed below are links to weblogs that reference Second Friends update:

Comments

"To update your status, simply make an HTTP GET request to:

http://artfossett.net/facebook/secondfriends/setstatus.php

setting the following attributes:"

Ouch! ;-)

Do you really mean GET? That's not REST-ful at all. HTTP GET should be used to obtain representations of current resource state, not to change resource state or create new resources, surely?

Imagine the case where a crawler/bot reissues GETs for some URIs it has stored (which it is a perfectly reasonable expectation): your current status would be changed every time. (I think the classic example of GET misuse on the Web was where some app was using GET to do deletes, and then they opened their server to search engine bots and watched the deletes pour in....)

I think you probably want to use either PUT (if the model is that a single "status" is being "replaced") or maybe POST (if you model it as adding a new "status" resource to a list of "statuses").

Ah, right. Thanks Pete! I did mean GET but I stand corrected. Given what you say I'll probably move to using PUT. Watch this space.

OK, the script has been updated to use an HTTP POST request - looking at the HTTP spec, I decided POST was more appropriate than PUT.

Great post Andy, you've got a quality blog.

The comments to this entry are closed.

About

Search

Loading
eFoundations is powered by TypePad