I think you would be best Campioning the easing of specific restrictions, rather than removing them across the board.

That said, I'm pretty sure that the grey-goo fence actually works. There was a dark period lasting a few months that happened a few years ago, when grey goo attacks got really "popular". Now, they're pretty rare. Is this because griefers got bored, or because the grey goo fence works?

The project works OK but my XML packets are taking random times between 15 seconds to over a minute. Don't tell me that this is deliberate and my project is down the drain?

Perhaps some warnings in the Wikis would be polite and save noobs like me a lot of time and expense - hard $US for a web site to handle the project!!!

There must be some solution or are we too much of a minority?

For example, if a script starts rapidly spawning copies, an alarm goes off somewhere in Linden Lab central, and someone investigates. If it is on an estate, the alarm could go to estate managers, as well. If it is on my property, let me know by IM or email.

Better alarms, better detection, and better correction tools would be better than arbitrary restrictions.

It's our world, after all 8-)

I also appreciate that while there are many better solutions to the XML-RPC abuse problem than doing the delay lobotomy, there are thousands of higher priority projects ahead of this so the chance of getting a better solution is very long term.

BUT 30 second+ delays are UNREASONABLE and kill legitimate projects along with the griefers. Rather than the original ZERO delay, one or two seconds of delay will still curb the griefing results but allow legitimate uses.

PLEASE - I did not discover this UNDISCLOSED delay until after 3 weeks of scripting and work on this project. It would be a simple task on the next rolling restart to change than delay back to a sane length.

PLEASE

1. This is an existing function that is failing about 25% of the time, not a new feature.
2. On applications using the XML-RPC functions the delays appear to be random and about 25% of those delays exceed the XML-RPC query time-out so the message fails and no acknowledgment is received from Second Life at the remote site. So even in quite slow, message situations, application data is lost.

Repeating undelivered messages only compounds the communication bandwidth load and increases accumulated delays to many minutes.

Please set the XML-RPC delays back to sane levels of a second or two to deter griefing and restore these XML-RPC functions.

Most of the delays are going to be permanent and until more complex policing method is in place, and with priorities the way they are, it could take years. Our only hope if we're stuck with them is to get them reduced to sane levels. This would be a minor edit and has a much better chance of implementation.

The XML-RPC delays running up to a minute and more are outlandish and constitute a bug by causing errors since the Internet XML-RPC response time-out is shorter than some of the script delays.

I was hoping to get better attention by converting it to a bug. I assume that updates have lower priority.

I don't know if that is good news or bad - an intentional delay introduced in response to the "grey goo" would be easy to correct. A bug may have to wait longer to get attention.

I think that a system of throttles, similar to what is on HTTPRequest is something that Linden Lab will accept. I doubt your bug, as it was written, would fly.

Please consider this compromise. We need to be realistic and take Linden Lab's needs into account here. We can't just ask for a free-for-all, delays were added for a reason, they are just a very bad solution to the problem.

Current delays and limitations encourage... actually, require scripters to resort to hacking instead of clean programming. This both makes code more prone to bugs, makes maintenance harder, slows down sims, and results in legacy code which either breaks once the platform gets upgraded, or worse, limits the way in which it does.

In any case, the LSL is currently the only programming language I know about which intentionally limits the functionality to achieve better security. This might work so far, but needs to change. I don't think anybody expects this to change overnight and without a lot of thought, but I sure do hope delays are not here to stay.

In my opinion, the scripts should be considered innocent until proven guilty, and delays should be introduced only after the script does a lot of potentially troublesome actions in a small period of time - but not before.

http://lslwiki.net/lslwiki/wakka.php?wakka=ScriptDelay

The problem with XML-RPC is definitely not a purposeful delay. It's just that that system hasn't scaled very well as more and more scripts have started using XML-RPC. There's an issue for that: SVC-29.

So when I say that the system is working as designed, I mean that the enforced short delays listed in my first link above are definitely working as LL intended them to... we just want to change their minds about the need for purposeful script delays.

The problem is simply the question "how to share the limited server resources between the users".

The current implementation of delays is not safe (users can work around it at the expensive of complex multitasking), not fair (more scripts inside the application give you a bigger share), and not resource-effective (you don't get the performance even if there are unused server resources).

A better solution to protect the server would be to use user-resource counter:
Any action performed by a user or one of his scripts he owns should have a resource measure which is added to his resource counter. The counter relaxes itself towards zero at a certain rate (like 1% per second). When one of his scripts calls a function then it will be checked if the user would overstep his allowed limit, and if this would be the case then the function blocks until the resource counter is relaxed enough to allow this operation (the time can be calculated from the relaxation formula).

Fair share:
Everyone who owns (or rents) a piece of land in a sim gets his share of resources from a "owner resource pool". Every visitor gets a share of a "visitor resource pool"

Performance effective:
Depending on how much the server is stressed, the relaxation time can be adjusted. This is the same as using time dilation. For an optimal use of the resources one would use several counters: a memory resource counter, a CPU time counter, and a bandwidth counter for requests to data servers, and sim-sim communication.

Ok, in all seriousness, I think it's worth noting that the Grey Goo fence is the primary defense against griefing, these delays are meant more as a defense against unintentionally bad scripts. Obviously script threading can bypass most of these delays, but the idea is that script threading requires intentional desire to bypass these delays and run these functions in sequence at that faster rate. Adding in delays prevents someone from accidentally including one of these functions in a for or while loop, or somewhere else where it might accidentally be triggered too quickly.

Replacing script delays with throttling might actually be worse, in some respects. Script delays allow scripters to anticipate the timing of certain functions and events. Ironically, for all the talk of policies that favor "honest" scripters over griefers (or my greater fear, incompetent scripters), throttling might actually be worse than script delays. A good scripter will work with the script delays to make a product that works in a consistent and predictable manner. Throttling would create a situation where the scripter knows that his product will work in a certain manner up to a point, but one that is sort of floating (a floating point? ok ok, bad computer joke) and imprecise. Script delays can generally be more reliable that throttles, which should only be used when absolutely necessary (sound throttling, for instance, is something absolutely necessary, but even then we've seen what happened with the first attempt at its implementation recently).

Finally, "multithreading" with scripts should not cause a significant amount of excess lag if it is done correctly. The communication between scripts needs to be efficient and correctly parsed. Yes, it is more difficult than if the delays weren't there and threading was unnecessary, but I think that what we're discussing here is more an issue of convenience than necessity.

I have no problem with discussing whether some script delay times should be changed, or whether some can be removed, but I think it's a bit silly to say that we ought to eliminate all script delays simply because they are inconvenient.

I don't think this is a good idea for the reasons that Jahar stated.

The reason for a delay is to discourage bad programming. Why not design it so it rewards good programming? You could forgive the delay for time run. Here is what I mean:
1) event is entered, a time counter is started that is similar to llResetTime()
2) some code is run
3) a function is called that has a delay, from the amount of time the event has been running it subtracts the delay of the function, if the result is negative, it sleeps until it is greater than or equal to zero.
4) goto step 2 if there is more code to be run.

A call to llSleep would let you pay forwards some amount of time. There would be a cap to the amount of time you could accumulate. Not all of a delay should be forgivable. There should be some portion that the user must pay then.

Jahar you said: "'multithreading' with scripts should not cause a significant amount of excess lag if it is done correctly."

This is not true. The LSL scheduler gives something like 0.001-0.003 ms of time to every running script. It doesn't matter if it's Hello, Avatar. Drop 5000 Hello, Avatar scripts in a sim and watch the script performance drop to total crap. So a good scripter is one that uses a minimum number of scripts.

The other big drawback is that it creates parallel programming problems that most LSL scripters should not need to face. LSL is supposed to be a simple language. Introducing unnecessary opportunities for race conditions and deadlocks is the opposite of what LSL is supposed to be about.

With Mono, we have the opportunity to eliminate all script delays. This may be our only realistic chance to do it for a long time. Mono will already break scripts that rely on LSL being slow. Eliminating script delays at the same time will not cause excessive additional problems.