On Thu, 6 Jul 2000, George Greer wrote:
> * Forget DG Scripts, we're going to have Perl, Python, and whatever else I
> can cram in there! Maybe even Java if the VM fits. :) Of course, I'm
> delirious from lack of sleep so I might be making it all up. LaTeX....
Basically, we're aiming for a language neutral embedded language. This
was the eventual goal of my script engine project (it was stalled in the
redesign phase: my life ran away and I've been playing catch-up ever
since), and something I still want to achieve. The problems begin to grow
exponentially as we approach more languages:
* Keeping bindings current. A change in a symbol might result in all
the language bindings going "sour." We would need to update each
individual binding to reflect the changes.
* Mapping data types and features across multiple languages.
* Security. This isn't difficult to achieve for each individual
embedded language, since the only ones anyone would/should be
looking at would have some method of restricted code execution or
running code in a CircleMUD-specified sandbox (Python supports both
in a few different ways). We would only need to decide on a
security policy to implement, and then implement it...
* Keeping security policies in line. Basically the same problem I
described first. With different security policies hardcoded into
the execution part of the script engine we get mired into updating
each language's bindings to reflect changes in the security policy,
meaning some languages' bindings will go "sour."
An intermediate step for expressing language bindings, security policy,
and data types might be the best solution. This would function something
like an interface description: a contract for security and bindings that
the embedded language is expected to abide by. A snippet of an XML
document describing the binding of the 'descriptor_list' symbol from
CircleMUD to a target language:
<symbols>
<sym list>
<owner>system:system</owner>
<perm others="readonly"/>
<bindto>descriptor_list</bindto>
<name>descriptor_list</name>
</sym>
</symbols>
The language API is specified internally, as in,
const struct LanguageInterface_data language_table[] =
{
{ "python", PythonWrapper_run, PythonWrapper_exec, ... },
{ "perl", PerlWrapper_run, PerlWrapper_exec, ... },
.
.
.
{ "\n", NULL, NULL, ... }
};
Some languages will map nicer than others to this. In fact, the Python
API's PyRun_SimpleFile and PyRun_SimpleString functions match the
definitions of runfile/runcode exactly. However, we can't use them since
we need to implement the bindings to provide for restricted execution.
Note that our code in the wrappers is fairly minimal. It might be better,
now that I think about it, to have initialisation functions for each
language that are called on bootup to do the majority of the binding work
and then make allowances to the strict bindings later on a per-user
basis. Any thoguhts on a good security model and implementation of this
would be intriguing...
-dak
+------------------------------------------------------------+
| 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