[sldev] Scripting projects priority survey

[Barney Boomslang]

Hey,
yep, I totally agree with Argent. Experiences from the Linux Kernel and the
OOM process killer there should be a warning sign to everybody - because the
one process that gets the troubles most often isn't the actual reason for
the problems. A much more deterministic behaviour would be preferable over
that idea.

(side note: my fav. point on the list is HTTP in, as that would allmost
remove the need for C# on the server for me - LSL would be reduced to UI
programming, for which it might be cumbersome, but useable, and server side
would work efficiently with the UI, without the need of polling. Yummy!)

bye, Barney

On Wed, Jun 25, 2008 at 3:13 PM, Argent Stonecutter <secret.argent at gmail.com>
wrote:

> The quota system as described in #1 would absolutely lead to content being
> broken, and it would almost always be content that was NOT the content that
> caused the lag that's being fought... since *that* content is already
> running. If you can't throttle scripts based on quota rather than simply
> block them, then you probably shouldn't implement quotas at all.
>
> I'm also concerned about the quota system that would be used. It has to
> allow significant overcommitment, because most parcels and most avatars use
> few scripts, and a parcel with 1/128th of the sim using 1/16th of the
> available scripting resources is common and not a problem, because scripts
> are dynamic, and 10 seconds from now it may be using 1/1000th of the
> available resources and another parcel's using 1/8th. Which is of course
> another reason to *throttle* rather than *block*.
>
> A comment on Tao's comment:
>
>> Besides that I would like to be able to use any language which can
>> produce an mono compatible output (I guess Python fits in there? :-) )
>>
>
> That will probably depend on the size and nature of the runtime. For
> languages like Python with a significant runtime of their own, and a runtime
> that includes "dangerous" APIs, I suspect it would take a significant effort
> from Linden Labs to support safely.
>
> I share Bruce Tong's concern about the security implications of allowing
> arbitrary CIL uploads. The SL environment requires more than usual levels of
> care... I would let the OpenSim people collect the arrow-holes in their
> shirts here.
>
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080626/fe0b3bf6/attachment.htm