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

Who pays? The creator or the owner?

If owner, how will you prevent anti-social people from intentionally giving someone a scripted object that will covertly exploit this to drain their L$?

If creator, how can the creator re-gain control to regulate their expenses if something goes wrong?

Will this be per-script, per-object, per-parcel, per-sim, per-agent, or per-credit card account?

Will there be some kind of IM/email warning when we reach the no-longer-free threshold?

Can we put a cap on how much we're willing to spend?

Can we have the option to invoke a time penalty instead of an expense, or when we reach the cap on what we are willing to spend?

Will we get a script event or a function call so we can determine when these thresholds are crossed? So, for example, when we cross the threshold we can tell the user "Sorry, this object has reached it's I/O limit, please come back tomorrow".

What if instead of above, my object says "Sorry, my I/O threshold has passed, please come back tomorrow, or pay $L5 to continue." Will we be able to selectively cross the threshold under certian conditions?

> Who pays? The creator or the owner?

Well, if we're talking strictly XMLRPC (are we?), then logically the person who is initiating the xmlrpc calls from the external server would pay, since the calls are initiated by the external box, so its easy enough to regulate them from there.

OTOH, how would Linden identify who to bill? I'm prety sure there are multiple XMLRPC streams coming out of my box, not just from me. To Linden, its just an IP address and a port number (I guess?), so they have no way of deciding who to bill, although I guess we could introduce some sortof authentication into the stream/packets?

If we're talking email, maybe the external person pays for inbound emails, and the owner of the SL object pays for outgoing emails? This implies that the owner of an SL object should have pretty tight control over regulating how many emails are allowed from an object per day, or something along those lines.

Azelda

Actually, the idea of having a local MySQL database for users seems pretty intresting.

XML-RPC is mostly used for storing data on MySQL and executing data on remote PHP scripts. A large part of the outgoing bandwidth can be saved by establishing several dedicated MySQL databases and small webspace quota (5, 10MB?) for hosting the necessary PHP script utilities.

LindenLabs conciders itself a hosting company - and so far the only thing they host is the grid and its Sims, with some basic E-Mail (that is only accessible via IMs and LSL scripts at the moment). Adding an internal MySQL service sound rather trivial in comparison to the work they allready do on the world, and will definetly expand some new horizons.

Correct me if I'm badly confused and paranoid (well, which I usually am anyway), but won't any version of this be death for the big PvP combat games now in the works. I mean if the weapons and game tags are communicating via email etc, yadda yadda yadda, any charge at all -- no matter how miniscule -- would add up in a hurry. Plus I wasn't clear on whether the charge would apply to private sims (since the justification had to do with server load).

WRT Uri's point, we won't put in limits or costs until there are object<->object communication substitutes.

On a related point, would people find object<->object communications within a sim useful? Note that would only be WITHIN A SIM

"runaway" script implies something that is not intentional. I think there is a need to distinguishing between an application that NEEDS to transfer a lot of data (for which someone should have to pay perhaps) and an application that has a bug.

Maybe a script that knows it needs an unusual amount of resources should have to state so at initialization. If the stated amount is exceeded the script would be stopped (automatically).

The other question outstanding I think is who would be charged, the runner (presumably) or the author or the script. If the former, there would need to be a mechanism in place for the purchaser of an object with a locked script to know of and approve of such overage charges. Seems like it gets messy just covering the basics.

i voted other because i can understand them leveling a charge for excessive use. if they don't do that, they'll eventually just have to put a hard limit on it.

would a method of implementing client-side storage help with this at all do you think?

> On a related point, would people find object<->object communications within a sim useful? Note that would only be WITHIN A SIM

Well, it would be useful, but its like shouts: its useful for small bits of land, but it doesnt scale.

My last biggish project spanned two sims, so it wouldnt have been really useful in this case. Whilst you could arguably set up a proxy system between the two, this isnt really useful with comms to attachments, which are floating freely to and fro across the sim border.

The number of projects spanning multiple sims is only going to increase, as SL grows and project management becomes more ambitious (eg see Robin's recent proposals to encourage larger projects).

Azelda

Have you informed the people who created or own the *many* runaway scripts that generate so much email traffic? I for one would like to know if I am causing problems with my scripts, so that I can recode them not to cause problems.

Maybe implement a system that will automatically notify people that their script is exceeding some bandwidth limit. To turn off the messages, pay a fee or something.

Charging for bandwith, wether it be for textures, object, scripts, script calls seems like a bad idea to me. I wasn't not here when ll charge each avatar ten lindons for each primitive created, but didn't it strife-fall creativity? Wouldn't scripter face the same problems as the builder did. I can't help but imagine textures create a similar drain on resources. But there are no penalties in place for textures, it could viewed as a double standard. Plus this isn't like a money script, where people can predict it's use. Most of the useful xml script, that I have seen, function through the use of 3rd parties actions.

If they have to click ok every time an xml script acts up, it reduces the usefulness of xml calls. But if there isn't then people will complain when hay wire scripts start to drain their lindons.

I think the second ll start charging per xml call. People will start to demand certain tools to manage xml calling. Like the ability to get a list of all script making xml calls that they own. And then they'll probable want to know how much each script is using. And then they'll probable want commands to limit how much band with each script can use. Ones they know how much band with each script isuing. They might want the ablity to limit each script, remotely. They'll probable want to be able to get the location of each script, and the ablity to disable each script remotely.

What happens when some one in a group make a xml script. Dose the group get charged for is use?

If your worried about bandwidth use, Why not have a command people have to set. Some thing like llSetMaxBandwithUp( integer ) and llSetMaxBandwithDown( integer ). When the script reaches it's max it could simply stop. Perhaps it could then trigger the changed( integer change){} function with it's own special static value. if ( change == Bandwith_Up ) if (change == Bandwith_Down ) Or just disable the script at that point and message the owner.

LL go ahead and charge yet again for something else, I double dog dare ya!

boo hiss hiss

> LL go ahead and charge yet again for something else, I double dog dare ya!

To be fair, LL do have to recoup their charges somehow. Hosting servers streaming absolutely tons of data is really not cheap at all. If you try to get your own dedicated server with that amount of bandwidth, it will cost you between 120usd and 200usd a month.

Factor in to that the cost of developing SecondLife itself, which is probably not insignificant.

That they've just received a VC changes nothing here: a VC is an investment, not a present. It will go into (in theory) future development.

Azelda

What would be done about situations like my email runaway in Seacliff, where the change in the llGetNextEmail delay caused a system that had been running without trouble for months on end to suddenly generate two orders of magnitude more emails than normal?

"XML-RPC is mostly used for storing data on MySQL and executing data on remote PHP scripts..."

Any technology at all can use XML-RPC, there are libraries and samples available for C++, Java, .Net, ASP, JSP, you name it. I use it all the time for cheap interop when I don't need the structure of WSDL and so on. There's a great, easy to use library from Cook Computing that you can download for free if you're a C# fan.

Unfortunately since you can't implement a call from in to out, I haven't found this to be altogether useful. I prefer to use one mechanism for a send/respond mechanism (as opposed to using one for one way and another for the other way), and at this point email is it.

You should be granted a tier of these kinds of services, which defines a limit, similar to objects and land. A reporting mechanism on the SL site, similar to land usage, could show you at any time how your bandwidth is doing. There should also be a script call that you can use, similar to checking your money, that allows you to disengage your RPC calls in the event you break a certain threshold (so you're not just racking up calls/charges without knowing it until it's too late and you're cursing at LL for letting your script run you into a pit of LinDebt.).

Overall though, c'mon SL is already expensive (yes, it is, unless you own nothing and have that one shot chatbot account). I'd hope the initially granted bwidth tier was GENEROUS, as in sufficient to run a decent application. Not just a way of giving you a taste of usage and roping you into billing.

I have no Idea what XML-RPC is.

Whoa, wait a minute, are you saying if we have a vendor that emails us for a transaction that you are looking at charging to email information although that information does not communicate back to SL?

If this is the case this is a very very bad Idea as it will deter all the people selling stuff in SL because thats how a lot of us use email as a double check for current sl systems.

If this is true then we will be punished for being entrepenuers...sad ...very sad indeed.

Shadow

Any object-to-object IM would be useful, even if it's within a sim. I presume this is being proposed to us becuase such a thing would be far more preferable efficiency wise than using the global object-to-object IM system (which I would still hope to be implemented).

More communication options are always good.

- llSay, llWhisper, llShout and llListen for the usual local channel-based communication

- llInstantMessage for object-to-user communication (for unattached objects)

- llLocalMessage for object-to-object communication within the sim, with no percievable delay. As a bonus, if this could be object-to-user as well, it would solve the problem where people want a way for an attachment to message it's owner quickly without the 2 sec delay.

- llGlobalMessage (or RPC) for object-to-object communication across sims, which I would probably expect a reasonable delay with since there is more message routing overhead

I wouldn't mind a very small cost on outbound RPC messages, as long as the cost only comes into play where absolutely necessary to prevent abuse, and only above a reasonable-use threshold, with a flexible way for you to configure soft and hard thresholds on your account.

PS: As long as we're considering bringing back taxes, how about reinstating the light tax?

I say yes, levy charges so long as everyone gets basic amount of calls they can use for free ... enough to support most end user apps.

For those of us who use extensive networking stuff, then yeah .. a fee is not a problem. So long as the end result is a more reliable system that doesnt make one jump through hoops in order to perform simple communication tasks, I dont mind paying at all.

-AP

Yes, this is absolutely essential for all kinds of games. Allowing us to get away from using chat would be a huge step forward.



Remember, though, the Lindens don't value the Linden dollar at all -- this has nothing to do with recouping costs or profiting from their subscribers and more to do with discouraging users from using XML-RPC or email profusely. Money only enters into it when lost Linden time is taken into account when horrible cascading email or RPC "events" occur.

It's the same as uploading textures, sounds and animations. The L$10 per asset uploaded doesn't go to pad the Linden Lab accounts, it serves to deter people from uploading millions of textures at once.

Ok I am still lost here. Again I ask does this mean that emails will be charged for any outgoing emails. Its kinda sad in respect to you have Yahoo-Free email,MSN-free email, most web service companies-free email. It costs nothing to send an email.

However I do understand in reference to the control systems that link live time to SL with sql and rpc protocols but email?

Nother thing...expect the value of the linden to be hoisted cause of this because that will start putting charges on Zeppi to trade lindens and the GOM Gang will have to compensate for thier losses.

Kex has a good Idea for LSL calls but Id say only charge for Global notifications if your going to and if its merely an outgoing email to a static address it should be free however if that email is sent to generate a responce from a server to reply with an incomming email Id say the incomming data should be charged...Just like uploads of textures and music.

Anyway still seeking answers.

Shadow

for object in the same sim

llLocalMessage(key recipient, string message)

What I would love to see is abetter object to object communcation for the whole world.
ie
llMessageObject(key area-code, key object, list message)

Area-cde would be sim related - object speeks for its self- list message speaks for its self.


Note: ideas belong to KexAtHome & AdamZ respectivly




Note note:

Response to hanks post below,

/me wips out 2"4" sized cluestick

/me gets out his cluestick.

Umm, we've been asking for this for months now!

/me grumbles

Thanks splat =)

The obvious benefit of the area code is to save routing through a centralized mechanism.

Whether that is in the form of a key, number, or whatever, as long as it's something static to that sim which saves as much centralized routing as possible (since this seems to be the primary concern with object-object communication).

Personally, I'd like to save the RPC overhead stuff for I/O outside the grid, and keep things simple for object-object communication within the world.

Cory, is there a set of parameters that you looking at currently? Previously you posted your goals or concepts on the Idea about changing the current permissions system. Is there any insight as to if this will be available for examination as well?

Shadow

Agreed!