[DGD] Letting the players code stuff

[Kurt Nordstrom]

Owww.  An interpreted language within an interpreter. 
Head....hurting...again... ;)

What about forcing user created objects to follow a certain framework that
would wrap the active part of their code within an rlimits() framework? 
The commands given to users could possibly check to make certain that
their objects are inheriting the correct code with said limitations before
compilation?

I need to think this through and come up with some sort of example to make
sure I'm not talking out of a non-oral orifice here.

>   This is something I thought about long and hard.  The short answer is
> that if
> you don't want players to be able to crash your MUD in some way, you're
> going
> to need to create an interpreted language within DGD.
>
>   The major concern is resource exhaustion -- you don't want player code
> to be
> able to steal all the machine resources and starve the MUD itself.  DGD
> has
> excellent protection to prevent this for disk space and processor load,
> and
> also does an amazing job with regards to security.  Unfortunately, if
> you're
> directly executing LPC code, there's no way to prevent player code from
> allocating too much RAM and starving your MUD.  To do that, you're going
> to
> need to add a layer to check that in some way, which basically means
> coding an
> interpreted language.
>
>   This language can look exactly like LPC if you want, though you'll need
> to
> figure out what the failure mode is when they allocate a new data
> structure and
> suddenly their code dies with an error of some kind...
>
> --- Kurt Nordstrom <kurt at blar.net> wrote:
>