Since HTTP-in was deployed in the recent Second Life server update, I’ve had a chance to bend, fold, spindle and mutilate it extensively. Essentially to use and misuse it in pretty much every way I could think of. And you know what? It’s nice, but it isn’t that big a deal.

HTTP-in allows an external application to send data to an object in Second Life, just as is done via email and via XML-RPC. About the only thing that HTTP-in seems to really bring to the table is simplicity and reliability. XML-RPC and email communications to in-world objects are highly centralized, slow, and not actually all that reliable. When you combine that with the setup and teardown requirements (both for you, and for the grid itself), things get pretty ugly.

HTTP-in is busting to its veriest seams with caveats, cautions and conditions, but it actually works and it keeps working, which by this stage – six years in now – must seem like a minor miracle at  the very least. Frankly, though, the single most effective use is signaling.

Unless you’re intending to pull data out of Second Life, you’re best off retrofitting your code to wait for you to poke it via HTTP-in and have it call your Web-server back to retrieve the data. It’s simple, efficient, faster than pushing data through, generally, and pretty much in 90% of cases that’s actually what you’re doing anyway.

Almost every scripted object using HTTP is pushing or polling – and HTTP-in doesn’t seem to offer enough advantages on its own to make sitting down and turning that model on its head worthwhile. Using the system as an external trigger to tell your in-world objects when to poll? Now that works a treat.

What you definitely need, whatever you do with HTTP-in, is you need some external repository that your in-world object can push its URL to, because HTTP-in URLs are darned ephemeral.

Region restarted? The URL becomes invalid and you have to get a new one. Script reset? Invalid. Teleported? Invalid. On rez? Invalid. Jump to the default state? Invalid. Detached or attached? Well, you get the idea.

Putting in everything to take care of that is wordy, but reusable, and almost all of us who have been using the other communications methods already have an HTTP-accessible registry where our in-world objects can store data like this, so it isn’t that huge a deal.

The number of potential incoming URLs is somewhat limited (limits operate in the same basic allocation fashion as prim-limits, and objects attached to an avatar have a pool of 38 possible URLs available to them). There’s also caps and throttles, but if you’re doing generally sensible communications coding, you won’t run into any of them at present – though there are hints that they may be adjusted in future.

All in all, the primary benefit of HTTP-in seems to be faster and simpler signaling to in-world objects, and that goes a long way towards reducing the level of incoming traffic at your HTTP server – and depending on the strictures of your hosting service, that can be a very good thing indeed. It doesn’t make choirs of angels sing, but it’s still a very useful replacement for email and XML-RPC communications.