3)
Yay. Modularity. Fault Tolerance. Function seperation. Whatever.
It's a good thing. I shouldn't have to cover why we want the
system to be fault tolerant. All the same, you might be drowsy after
reading to this point, so lets go through the salient points.
- Ease of testing/debugging
Seperation is great - you can't affect the other parts of
the (working) system, and they can't affect you. That makes testing and
debugging that much easier, when you can eliminate a large source of
unknowns. This is also important when considering pre-existing
interpreted languages - many are difficult to debug because you have to -
in effect - provide the end user with a debugger that can be accessed
THROUGH your mud. This is a severe pain in the ass - most people don't
have the ability and you'll get alot of severe errors with 'Seg Fault' or
something simliar being your only indicator.
- Drop in replacement (per Object Oriented paridigm)
This is actually an interesting case - aside from the
advantage of treating a script like an object (and thus being able to
chain script/script-parts together), the largest benefit to this is to the
programmer of the script system. Instead of having to manage
unconstrained and diverse 'bits', they can just write a simple generic
solution. Fewer points of failure = good.
- 'Crash' protection
Perhaps the most important bit, you don't want your
builders crashing your mud. You don't want them slowing it down or
impacting the system at all. In fact, depending on how you make your
sandbox, you may not even want them to be able to run certain commands
without authorization! The sad bit here though, is that you can't rely on
an external interpeted language either; it's hard to validate that a perl
script won't go in a continual loop, or that java won't have a required
try/catch around a piece of code that didn't use to require it (damn
library upgrades).
Just like in computer security, the easiest way is to eliminate
everything, and then only allow the things you know about specifically.
You can't do that with an external language, and have to end up allowing
everything and scrambling to catch the cases where you think it may be
bad..
----
So, where does that leave us?
Well, in my supremely opinionated view, you'd be wasting your time
if you focused on a solution intended for Circlemud 4.0 that relied on
including any interpreted language. Time should be spent on making a
internal language (though it could look like a preexisting language) which
has as it's primary goal; "Usable by non-programmers, and those who never
want to learn to program". In fact, as I mentioned above, that language
should be a BIG part of the internals; it'd be worth it to design most
major interactions within the code with a scripting system in mind.
Frankly, the inclusion of those preexisting languages would simply
set you back even further than just relying on specprocs. It'd just be
neat to do, but god help you if you let anyone use them.
Comments welcome, criticisms expected.
Also, my personal respect if you read everything, wow, you're
dedicated.
PjD
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
| Newbie List: http://groups.yahoo.com/group/circle-newbies/ |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT