XML-RPC Outbound Is Enabled

... Kind of... I thought of this lightning flash idea while sitting at work.

You can change the streaming URL for a parcel with the LSL. So why not have a web page that actually doesn't stream, but which captures any HTTP GET variables supplied to it. Your stream request fails, but in a split second, you transmit out any number of HTTP GET variables including possibly an ID code for which prim it is which is talking etc. And then your server knows your prim wants to talk, so it can then initiate X number of XML-RPC calls.

Genius eh?

Freeview actually does something like this.

Cue CrystalShard spam.

Brilliant tip, Jsecure.

Tho, someone has to be on the parcel .. which is a minor problem.

This is awesome!

Damn... Didn't think about that one... Alright back to the drawing board...

So we're stuck using emails for getting the keys of XML-RPC active objects ?

Why the sad face? What don't you like about email? To slow?

I cannot use this method with the webhosting I have right now... So short of making one-time experiments I can't really use XML-RPC at all.

[Edit] This is clearly a problem. I make a living solving problems. So I'm gonna solve this one. *rushes out* *sounds of old dusty tomes being opened and browsed feverishly*

<takes her cue>

llLoadURL() is your Savior.

Amen.

<stage exit right>

<applause>

This I could use for a number of personal ideas Thanks.

This is clever.

llLoadURL is alright, but for the other half of XML-RPC it has some usual flaws. It delays a script by ten seconds, which is an age, and also it'll only work when a URL is given to an in-world avatar, and only if that avatar then goes on to load up the destination page.

So for now the closest solution would be setting a streaming URL to something with HTTP GET data while people are present, else using email.

The latter two are given if the person actually wants to use whatever service you're setting up.

As for the ten-second delay, a little multithreading magic can work around that quite handily. I'm guessing the delay here is based in the script itself, so splitting it off and using a link message would get the job done quite handily. If the command is really anal, as llRemoteLoadScriptPin is, you can use separate temporary prims and a listener.

Not really.. they'll shoot off an XMLRPC message as long as they have streaming enabled. (Which, for my accounts, I do not.. another minor problem

also a lot of my XML-RPC tools I have in my head would function with nobody immediately present a lot of the time.

Logic err, my part. To clarify, by latter two I mean:

1) "t'll only work when a URL is given to an in-world avatar"
2) "[O]nly if that avatar then goes on to load up the destination page."

... for llLoadURL.

Streaming is a completely different animal.


As for this:

From: Jsecure Hanks

also a lot of my XML-RPC tools I have in my head would function with nobody immediately present a lot of the time.

If that's the case, can't you just send a request in from out-of-world and reap the reply? Or does that defeat the purpose?

Streaming is a different animal but it's still done entirely by SL clients and not LL servers. So if you switch a parcel streaming URL to something new, then nothing touches that URL unless an av is nearby and their client tries to stream that URL (hence why you need someone to be standing on the parcel for that to work).

I already do send requests in from outside SL to poll my prims at hourly intervals, but it would be far more efficient if they could cry out when they needed attention, as at present I have to run a dedicated daemon on my server just for polling prims every hour.

Been trying to bite my tongue on this offer... but... whatcha doin? I can create an email to HTTP post proxy for you if you like. Anything you send to a magic email address would be redicted to an HTTP post. Think there is general interest for something like this? One proxy email address people could use, and an email format that specifies where to redirect? Send me an IM if you'd rather discuss it privately.

I think that'd probably be quite useful to a lot of people. I was going to set up an incoming email address on my server that my prims could email to for help, but I never got around to it in the end and I just use XML-RPC pooling.

If outbound XML-RPC never materialises, I'll probably proceed down that route, but those who don't have access to the resources I have might love the service you mention.

You can use Exim or procmail or somesuch email filter to pipe incoming email directly to a PHP script, which can then reply via email or XMLRPC, or do whatever you want.