Help for people with port 25 blocked please

I understand, Mark. And I'm not ranting. Well, actually I guess I am...

I guess I'm just disappointed that XML-RPC isn't what I had envisioned. And as a result, most of the projects I've had in mind for the past 8 months are going back into their folders to collect dust. :-/

All I ever really envisioned myself doing in SL was scripting, really. I'm an RL developer, but I specialize in database applications. Without persistent data storage, either in-world or out-of-world, I'm kinda useless.

Alright guys they beat us up with this a bit, it's not what we wanted. But we have no specific right to the tech, so we have to pick ourselves up and dust ourselves off.

For those of us who it's possible, the clear answer is for our HTTP servers to do NOTHING, and wait for a custom email client to receive an email. When the client receives an email it pops something in the database saying we should do something. Or it calls a web page. Or does something that tells the system, you have to contact SL now.

So this is like a bypass operation. We bypass that XML-RPC can't call out, by calling out with email. For the time being that's how it is, and we should see what cool stuff we can build with what we've got. I'm sure it's a huge job to get all XML-RPC up, and I'm sure the rest of the implementation will come as fast as poss.

I'm sorry for those who can't do the custom email client, but for the rest of us, let's begin building.

For those 'service' minded out there some good L$ (or community good will if thats your thing) could possibly be made by offering an email -> XML-RPC relay service. Accept emails from SL objects and redirect the message to a specified XML-RPC setup. A service for those who can't have the custom email client as Jsecure mentions, or for those too lazy to set it up.

How about limiting a user to 100,000 outgoing XML-RPC requests per destination IP address per day? Even if you max out the request size, that's only 50MB of data. You can DoS a dialup connection with that, but not much else.

How about requiring a user to register what server/servers they want to use with LL?

Good news Ama, I have an algorithm in my head for how that could be done, and I have an exam tomorrow (Friday) which is causing me to stop all coding (And then I'm at my girlfriends' till Monday) But after that I'll be making it my top priority

It is my goal to make XML-RPC a thing that most people who use don't understand that well... Cause they don't have to. I'm going to build a series of drag and drop components that just automate the entire process, and DO finally sort out persistent storage once and for all, and do it all drag and drop.

I hope I can assist all your data warehousing needs in the coming weeks, and I have some pretty impressive prototypes already, but these won't be revealed till complete

XMLRPC as it is going to be implemented (to my understanding) does not appear to have substantial advantages over the current email implementation.

The only benefit I can see is the ability to send an immediate reply to an outside request.

Email:
+ can send/recieve 4096 characters
+ inherently queued without any setup
- difficult to work with when all you have is a *web* host
+ no delay recieving email
- delay when sending messages outbound (but at least you *can* send an outbound message)

XML-RPC:
- only 256 characters & 1 integer
- requires you to create an RPC "listener" with OpenRemoteDataChannel before you can begin receiving data
+ can create an immediate llRemoteDataReply()
+ no delay recieving messages
-- can't send outbound messages at all

XML-RPC hopefully will be faster and more reliable than the Email function.

Plus as a developer, I like the idea of XML-RPC directly calling PHP on my HTTP server a lot more than I like a system where I have to break down emails for data, and then relay this to my database.

I think in time XML-RPC will be used both ways, but when the Lindens mentioned DOS attacks, I realised there was a spectrum of things I hadn't thought about. I only think as a developer; they look at the whole picture.

Till XML-RPC is fully functional, I think it will have at least some benefits in that data can be written once using email and read many using XML-RPC, a preferrable standard in my mind, to email.

As for not being able to initiate XML-RPC from within SL, I have covered this with the idea of using an email based trigger, telling a server it needs to get in touch with SL.

I'm certainly all over this and will be implementing a number of devices which make getting the best out of email/XML-RPC a simple task.

That will completely kill the reseller market for RPC-hosting.

And it will severely restrict the usefulness of XML-RPC on large projects, or popular items intended for resale.

There's a factor that overrides all your plusses and minuses: if you're running this from your home computer, a hundred thousand outgoing XML-RPC requests looks like normal traffic. A hundred thousand outgoing emails looks like you're running a spam relay.

Yeah, I realized that last night. A hundred thousand requests sounds like a lot, until you realize it's only a little more than one request per second.

So, have any you tried out the XML-RPC implementation on Preview? What did you think?

It's fast. Very fast. Please don't cripple the speed when it goes live. ;)

The only real problem I ran into aside from the lack of an LSL rpc client was it doesn't appear, or at least is completely non-obvious, where the integer value in the result strcut gets set. The llRemoteData rpc call says in the preview guide it returns a struct with an int and a string. The llRemoteDataReply() in LSL takes two keys and a string. So which one is wrong?

As it is though, I can't think of anything but completely trival uses for only having the server in LSL, stock tickers, "What's my Winamp Playing?", etc. Please work out the liability issues with the rpc client quickly.

We don't intend to make it slower when it goes live.

The lack of the integer value in the result is a bug; the function llRemoteDataReply() will be different in the next Preview release.

As for non-trivial uses: you could, for example, create a Mars Rover that responded to commands from a webpage, and returned position, locale information, etc. You could use this to build sensor nets.

What is the non-trivial use for the XML-RPC client that you can't do with the XML-RPC server?

Basically with the client you've got high speed two-way communication. To me, getting things out of SL is much more interesting than pushing things in so the lsl client interests me much more. It's like, I could build the remote-control death robot, or I could build the remote control death robots that tells me about its surroundings. Sure, I could poll as you suggested but I really don't think it should be required. It increases network utilization on both ends, when it can be done away with.

The one thing I'm definitely interested in doing is a speedy SL/IRC gateway. It's been done already with email, but the round trip time is high enough that conversations across the gateway get badly out of sync.

I'm sure that eventually you will get around to adding the client, and I understand the liability concerns. It's one thing to create a possible instrument of destruction and ddosing against yourself, and quite another to be an enabler for inflicting that on others. For now I'm planning on rolling up my sleeves and digging in to see what there is to see. But I do hope we see the two-way channel sooner rather than later. Having both xml-rpc and email as bidirectional communication will allow for more people to take advanage of them.

Data storage and retrieval in a real SQL database via a webservice!

Persistent storage is the #1 obvious answer to this, but rather than give a long list of specific instances where an RPC client has more utility than an RPC server, let me describe why a client has more utility.

The internet is still bigger than SL, encompasses more data, contains more information.

There are two perspectives: an internet observer looking in on SL and a SL resident looking out to the internet.

Which perspective benefits more from having a communications link between the two? The latter. It's like information osmosis. There's more information pressure on the outside wanting to seep in, than there is on the inside wanting to seep out.

Why? Because there is less information that is interesting inside SL than there is on the rest of the internet.

LSL is hungry and needs information. It would be able to gather information much more elegantly by proactively fetching it rather than passively waiting for it to come.

Mark, how about enabling outgoing XML-RPCalls to your own servers only? This would allow object-object communication and you wouldn't have to be afraid of bringing the wrath of the internet upon you.

The size limit of the string parameter to 255 characters is way too short - whats the reason behind this? IMHO it should be closer to the 4000 characters allowed in emails.

There is also a limit in the design: No way for two objects to initiate communication via XML-RPC, simply because at least one would have to know the other objects channel. They'd have to exchange these by other means - perhaps you should consider providing such a way, so people without a colocated server can use this feature. Not sure how, maybe some kind of service where one object could register itself with a shared secret and the other object could query for that and get it's channel in return.

Ezhar: Great suggestions.

I forgot about using RPC for in-world communications.

A maximum string length of 255 seems rather arbitrarily low; I wish it were higher, then we'd be less likely to need to do packet re-assembly for some things such as an IRC relay or a single row SQL result.

One solution to the handshaking of communications is to create your own "DNS" of sorts, by establishing one constant object that handles handshaking for all of your other objects. =)