SecondLife is going to start charging users for XML-RPC calls?

SecondLife is going to start charging users for XML-RPC calls?

What the hell!?

I'm going to say no, with the qualification that Cory didn't detail what he meant, so I am not totally firm on it.

I'm curious about how this will be implemented. Is the script owner charged, or the script creator? I assume the owner, but I had to ask. This could break some of those fancy auto-update objects that may use XML-RPC to "Phone Home" now and then to check for updates.

However, I'll vote 'Yes' with the following conditions:
-- comms has become such a drag on the server that limits are absolutely needed.
-- the rate package would allow a certain number of free calls before charges apply (for instance, you get 48 calls/day, over that and you're dinged L$5-10 per each subsequent call)
-- no sleep timeout after send/receive

I think they should charge per button we press while in game.

Nothing has been decided on this, but one rate limit model is to charge L$ per some amount of bandwidth used (since this eats up server resources). For example, it could be "if you exceed this large number, then we start charging."

We have had *many* runaway script email transmissions that have ended up causing problems, so the goal of rate limiting is to pick large limits that don't impact the system and to then limit above that.

A different model would be to just limit everybody to some fixed amount, but it seems like charging people who want to exceed it would be a useful way to load balance. Obviously, XML-RPC and email would be charged differently, as would comms within the world versus comms to outside connections.

However, this is not set in stone.

I voted that this is a good idea. Another way to get L$ out the economy, and, people SHOULD pay for the bandwidth they use!

I just hope poorly written scripts that wind up costing the person a lot of L$ can be avoided easily.

what is XML-RPC??

voted yes just to piss all of you off.

xmlrpc.com

In short, a way to interface between objects in SL and remote systems, such as your own database, a chess-computer, a web server, or what have you.

Some points:

- Email is one of the best features in SL currently, becuase it adds a lot of creativity to be able to create with one's preferred tools (Python, CVS, MySQL etc). It would be a shame if anything were to stifle that.

As far as bandwidth, most of our bandwidth usage is reciprocated at the hosting end. If we go too far overboard, our hosting is going to chop us off pretty quickly. That said, the bandwidth on the hosting is not *that* expensive. I'm paying like 0.77usd / month for effectively unlimited bandwidth for my current needs. So, it would be a shame if a bottleneck would be added at the LindenLab side?

> "For example, it could be "if you exceed this large number, then we start charging."

If the number is *large*, that could be workable, but it would have to be quite large. Any project using xmlrpc/email is bound to chew through a fair few bytes.

Perhaps you could start by putting in place an automated warning to those who are using a lot so at least we can have a feel for if/when we are going too far?

- y'know, if we had our ShellServer at LindenLab itself, that would solve soooo many problems. On the one hand, that kills this potential xmlrpc cost issue stone dead, and on the other hand that would open up lots of doors, such as writing our SL scripts in Python, Perl and so on directly on the ShellServer (just put a firewall between the ShellServer and SL, perhaps a little SL-specific proxy too, I can probably write that if you want).

Azelda

I think it's a bad idea because I'm already paying for that bandwidth through my private dedicated server that I lease, which is $90 a month. If I go over my bandwidth there, I'm looking at 100s of dollars in fees on top of that. To the Lindens, I'm already paying $40 a month in land fees and am upgrading to $75 soon, plus $9.95 for the premium account... you want to nickel and dime me now?

This really depends on what "pay" is (i.e., is it a superficial amount or are we talking $L10/packet). If it would mean a fast and constantly running email/rpc system (preferably with outbound rpc while we are at it) and the price is relatively "pay barely squat if you don't do silly things", sure....

Although, I have to say, Azelda is onto something there.. it would be wonderful to be able to access Perl <-> SL bit with less "fuss" and lag.

Well, one important thing is that they should increase the amount of XML data in the string val.

Currently, I think the packet data is 75% overhead and 25% actual data. Charging us for overhead seems a bit silly for all concerned.

They could also provide us with more tools to compress data as well so that we can better use the channel. For example, instead of having to send integers as strings, we could send them as 4 bytes.

Paying some token amount for consuming resources makes sense to me. It does not even have to be proportionate to the actual usage (however that would be measured; I have no idea). Any cost at all would deter some misuse, and perhaps motivate some to code more efficiently (or maybe not).

I am wondering though -- how would any charge scheme help with the runaway script problems Cory mentioned? That sounds like something that would be caused by a bug in my script. I make a small typo in my script, and the sim still gets hammered -- at least until my bank account runs dry.

Although I am not fond of them, script delays tap into an (effectively) unlimited resource: time. Tapping into the bank account (a limited resource) is a whole new model. Does this mean that people with low balances would have trouble experimenting with communication scripts? Would they be able to use a communication device if they bought one?

Potential new model -- lots to think about.

Yes, if the value is set high enough AND object <-> object IM is in place.

upon reflection - yes!

i don't feel like covering the costs of stuff i don't understand and will never use. if i buy an item with this feature then i can pay for the usage, but i do not forsee myself outside of the usual category of land, vehicles, and av accessories.

I would imagine the jury should remain out on it until we find out what their actual plans are. Too many conclusions are jumped to from small statements made in a town hall with little information. They have hardly been outrageous with fees so far (land tier fees aside), why would you think they would suddenly screw advanced scripters?

It's worse than that. As far as I've measured it, best-case performance is 80% overhead. Average-case perfomance with my current XML-RPC application is 99.2% overhead. For a single run, I'm transferring approximately 125MB of data to get 200KB of results.

I think charging RL cash would deter players from trying XML-RPC, fearing it would cost them more than they could afford to make a mistake.

Also I for one would want a VERY clear warning on any items using XML-RPC. I would probably not buy them at all fo fear that a poor scripter would cost me a fortune.

> Well, one important thing is that they should increase the amount of XML data in the string val.

Dont know about anyone else but I *only* use email. Payload size is one significant reason why, as Blaze states, and the other is it means I dont have to handle sim-crossings. There's no particular advantage of XMLRPC as far as I can see, currently, except a slight reduction in RTT, and less load on my hosting.

Azelda

There's also the advantage that, if you're running the script off your home box, with XML-RPC you aren't risking having your account suspended on suspcion of spamming.

If bandwidth is an issue Id prefer a raw UDP connection to my scripts, lol
I've always disliked XML-RPC because of the inefficiencies.. I still haven't learned it..
Makes me feel dirty, kinda like scripting in an interpretative language. (SL excluded, it compiles)

> There's also the advantage that, if you're running the script off your home box, with XML-RPC you aren't risking having your account suspended on suspcion of spamming.

I suspect that a fair quantity (>50%?) of people on the hosting I use are using it to connect to secondlife. The host probably knows exactly what is secondlife by now IMHO.

Azelda

Cory mentioned per-user rate limiting ... perhaps via a very small cost. Would it work to use the rate-limit as the cost?

On a per-user basis, the first block of calls would get no script delay at all. The next block adds a per-call delay. Each additional block gets more and more delay.

Perhaps this would make data-intensive projects prohibitively expensive. And one user with multiple applications could see performance/timing oddities. Hm. The idea needs a lot of tuning, but I like the idea of paying with time.

[Someone else mentioned the idea of using graduated delays before -- sorry I cannot find the post to give you credit.]