[721] in Coldmud discussion meeting
server extension
daemon@ATHENA.MIT.EDU (Mon Mar 20 08:41:54 1995
)
From: crag@serial.MIT.EDU (Robert de Forest )
To: coldstuff@MIT.EDU
Date: Mon, 20 Mar 1995 07:29:04 -0600 (CST)
Ok, I have nothing firm in mind, but while I have anything in my mind at all
I want to write it down and send it here.
The objective is to be able to add functionality to the server at run time in
ways other than writing in-db code because interpretation is inherantly slow
except for languages like Forth which are just plain confusing and not overly
popular compared to structured compiled languages like C.
My first instinct is to provide a way to 'import' new class objects. What I
envision is that you'd tell the running server there's an "object file" at
a certain location in the file system and that you wish for it to be added
to the server as a new object. Something like import("extensions/bitfield").
The return of this function would be a new dbref which acts like a regular
object as far as the db can tell. When the object receives messages it turns
them into API calls. I guess this is kinda like a Windows DLL...
We'd need a way to verify that an import object was 'valid' and wouldn't crash
things. Allowing people to link in code at run-time is just BEGGING for big
trouble in the form of destructive crashes and viruses. One way to help
prevent this is to limit the level of access the object has. Perhaps allow it
to run as a seperate unix process to protect the server and limit interaction
to the same methods in-db objects use?
I don't know what the cost of starting a new process in unix is. I also wonder
if doing this would kill whatever speed gain we attained. Is process-process
communication fast? Perhaps we could offer multiple trust levels. Untrusted
modules could be imported in a slow but safe way and as they earn trust more
could be given to them and they could run faster?
There are a lot of great things about this. We might be able to get speed and
true language independance this way. If we had an export that compiled in-db
objects into an importable format we could use these as transportation
methods, perhaps... Best of all, we could export to C source, optimize it,
compile to assembler, optimize that, assemble it and distribute it as
an importable module. If all or most of the core funcionality were turned
into modules people could come up with things like list-0.1.2.ci-, a version
0.1.2 c- import file to upgrade the list type.
All of this is very hazy to me right now but maybe someone else will have
something to suggest to make this a little more realistic.
Incidentally, since I will be providing the parser tree and allowing people to
compile raw parse trees to methods we will be able to add new operators in-db
if the code interpreter will support them. Maybe we should change the
interpreter to allow 'unknown' operators and send messages to the first
operand about the operator to see if it recognizes it, then to the second
operator, etc. This would allow some insane person to make string addition to
non-string types to work as if the non string types were string
representations of themselves if they provide a way to get that rep.
Er, I mean, "foo" + 1 could be interpreted as $string.add_op("foo", 1) which
would generate a $integer.to_string(1)?
I am eyeing myself warily now...
Crag