Web to SL realtime communications

Hello,
i'm trying to find the best solution to do communication from web to SL in realtime (not viceversa); what i need is a symple system that let me send messages from the web to avatars or objects.

The solutions i found untill now is:

1) email: but it take a lot of time, some people said that the mail can come with 48 hours delay!!!
2) a timer in an object inworld, that every xx seconds send a request to the web and wait for the reponse; but it is a waste of resources, and not really realtime!!

What i need to know is, for example, how Slexchange can send an object in the inventory from the web in some seconds... any idea?

Thank you very much and sorry for my english!

XML-PRC is what you seek:
http://lslwiki.net/lslwiki/wakka.php?wakka=XMLRPC

It allows external apps to speak to scripts in SL over a HTTP communication sending XML formatted data.

oh thank you very much!!
i give it a try now!

ok, i tested it and it is really fantastic!!
Now a question: is possible to send and xmlrpc call directly to an avatar? example to send an IM to him without login? Or i need to sent the call to an object and forward it by llInstantMessage()?

This is an extract from an email sent by Kelly Linden to the sldev mailing list (which is generally aimed at open source viewer developers, not scripters):



And later on...



Just thought I'd throw that out there Hope posting it here is ok, the mailing list has open membership and is publicly archived too. The full message can be found here https://lists.secondlife.com/pipermail/sldev/2007-June/002245.html

Yes, I switched all my email and XML-RPC communications to simple http pings and never looked back. What a headache nightmare that used to be.

Good to know, thanks for the posts.

HTTP polling is much easier too. At least it is for me, since I have several years experience with Web based forms, ASP and associated tech.

My only concern with HTTP polling would be the possible heavy traffic result on a Web server.

SLX doesnt send an object "from the web". There's an in world object (the SL magic box) which contains the item, and a script in the magic box receives a request (from the web) to give the inventory item to the avatar.

Yes... HTTP polling would be great if you didn't have to pay for traffic to the web server.

Are you paying by the hit or by the byte?

Because my SL HUD game has hit my webserver about 300,000 times this month so far, for a grand total of 16MB of bandwidth (incoming + outgoing). That's about 1/10 of a percent of my limit, for which I pay $8/month.

If anyone needs proffessional & reliable web hosting at very very cheap prices, IM me in world 'raidingyour Chambers'.

Theres already a _free_ and very professional solution for www to SL text communication, it is developed by a friend "by accident":

http://www.sim2-0.com/kitcom/

"KitCom is a free World Wide Web to Second life chat application. The first tool enabling text communication between a website and your avatar in realtime. Your chat partner needs no registration or login at Second Life."

It's really helpful and fun, especially the multichat inworld, there is an English and a German version, check it out.

If there is anybody interested to extend the php-side (www-interface), please IM Miki Gymnast inworld. Its a non-profit project.

i can understand the Linden position about the "single point of failures" of a central apache hosting the cgi; but... don't say that pinging a webserver every second, to find an event that probably come one time in a day, isn't a waste of resource!

A single object, if i ping like you are saying, ping my webserver 2582000 times in a month!! And what about tha case that i have 10000 objects pinging? I have to rent a webfarm to handle the requests?

Probably is the case that LindenLab take a big cluster on the cgi machine; it is impossible to think this service deprecated!!!!!

Sorry for my henglish, i hope you can understand my position!

Pinging a webserver constantly is a waste of resources. However, in terms of reliability and sim resources used, it's miles ahead of xml-rpc and email.

It's your choice anyway, I only posted that because it's obviously pertinent and obviously comes from a reliable source.

Not to mention this little roadblock regarding HTTP requests...

"Requests are throttled to a maximum of 20 requests per 100 seconds". So pinging with an HTML request every second isnt even allowable...Unless you code around it, which sorta defeats the purpose of the rule, right? Which if I understand correctly the HTTP restriction is sim wide and not per script.

Another possible flaw in this HTTP poll suggestion is the requirment of transferring data to the PHP script which could require more than 1 packet due to the string length restrictions. The poll methodology would trigger a different PHP instance and thus some logistical complications needing to temporarily store bits of data till it all had arrived... do-able with sql and some id tags but what a pain in the but... with rpc you just send a couple rpc requests and you have your complete set of data. Granted 3seconds per chunk do to the RPC responce built in delays.

I may end up having to go this route do to the reliability of incoming RPC packets dropping. but repeated HTTP polls... for infrequent events...wastage...bigtime.

This feature should not be depreciated, work should be done to make it more robust, not just give up on it because its a challenge.

-Phid

It may FEEL like wastage to you, but did you actually read what Kelly Linden said?

Btw, they changed the HTTP limit to 100 requests per 100 seconds. See here for lots of info and links on that: http://lslwiki.net/lslwiki/wakka.php?wakka=llHTTPRequest

I did read that post, and I do understand the issues going on... I just think its a terrible band-aid.

When I said wastage, I was meaning for the individual Web servers being pinged constantly. Not that it adds up too much but you never know how many object instances you may have that needs to communicate (per application) so it could be bad depending on the design requirments.

If it were me... and its not... I would introduce a "per-sim" XML-RPC interface, the current version already spits out the "Channel" which needs to get transmitted to your PHP anyways (probably by HTTP), just add an additional piece of data like the RPC handler link for that specific SIM once the channel is opened... Then just send both tidbits to your PHP/Sql script (Sql to hold the data of course). Thoughts?

-Phid