From: "Patrick Dughi"
Subject: Re: [CIRCLE] forgot
> Would time be better spent developing ways to access and
> integrating external scripting languages or redesigning the mud layout so
> as to lend itself better to a single custom, internal scripting language?
>
> I personally think that one custom language would be better suited
> than making it perl/python/scheme/sml/C#/tcl/basic/java/whatever. None of
> these have what it takes to insure mud-level security, and at the same
> time be responsive to the most common scripting commands... the only thing
> they really offer is the control mechanisms (while, if loops), and direct
> access to variables, as well as aids in variable type conversion.
> However, even for the sort of kludge it is, dgscripts already provides all
> these admirably enough. Shouldn't we concentrate on making what we have
> better, rather that starting over with something that isn't even made to
> integrate with our mud in the first place?
>
I tend to agree. Since most(all?) programming languages are made with the idea that they should be able to tweak most variables, to be viable for ordinary programming purposes, they fall short for use in internal mud scripts due to security issues.
As someone stated in the recent discussion about the MXP protocol, a server/mud should not assume all scripts/users to be friendly. If a malicious script is written, it should be dealt with automatically - a solution dg_scripts solves very well. To implement ie. C as a scripting language would require implementation of numerous security measures for each possible command or a limitation of which commands are available to scripts - which in turn invalidates the reaons for using C.
Basically this was just to say 'I agree'
Welcor of Cruel World
midnightrealm.org 4000
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT