|
Ephyu Reino
Registered User
Join date: 18 Jan 2007
Posts: 16
|
12-15-2008 07:33
What's the best way to have an object delivered in-world based on actions on a website?
I need to allow for relatively quick delivery (less than a minute from site action, ideally), requests for (potentially) large numbers of items from multiple people, and I don't want a heavy/frequent load on the web server (hosting company doesn't like automated page loads).
|
|
Pedro McMillan
SLOODLE Developer
Join date: 28 Jul 2007
Posts: 231
|
12-15-2008 09:21
There are 4 ways to go:
* Email -- send an email using PHP on the website, but it relies on knowing the UUID of the object to receive the request in SL, and relies on the object in SL polling regularly for new emails
* HTTP polling -- the object in SL regularly requests a page on your site, asking for any new details (such as requests for objects). Can be quite slow, and put unnecessary load on your server.
* XMLRPC -- not wonderfully well-supported, but it works, and it's usually only a few seconds. The object opens an XMLRPC (aka remote data) channel in-world, and sends the UUID of the channel (NOT the object) to your webserver. Your webserver then sends an XMLRPC request any time an object is requested. We use that method for the SLOODLE vending machine (which is open source, if you're interested).
* HTTP server -- this isn't on the main grid yet (as far as I know), but should be very available very soon. You'll be able to setup objects in SL which act as mini-webserver, so your website just notifies it of an action using the cURL extension (or such like) to request the appropriate URL. Should be excellent when it's ready (like a better version of the XMLRPC implementation).
EDIT: oops, forgot to mention a recommendation! (Having an odd day...) For moderately frequent requests, XMLRPC is often the best and fastest method at the moment. If you end up with quite high volume though, you might want to consider 'caching' your requests on the site (in a database) and then periodically sending several together into SL via email. Slower, but probably more reliable.
|