[vworld-tech] Modern MUD server design

[Mike Shaver]

On Jan 22, Brian Hook wrote:
> Well, unless Bruce objects, I would think JS embedding is actually the 
> kind of thing that a lot of people here would be interested in.

OK, that sounds reasonable, then.  I'll try to find some time this
weekend to answer Bruce's laundry-list of questions.

> Like I said, if someone is being fairly conservative, given the 
> information available, JS isn't much of a candidate if you're 
> concerned about performance, either because existing data is out of 
> date, inaccurate or non-existent.

If you're being conservative, I submit that making performance analyses
based on isolated benchmarks against unrelated implementations is
unwise.  Your load is, I imagine, unlikely to closely mirror the GCLS
test suite, and will be much more significantly affected by things like
locking efficiency, threading-friendliness, cache footprint,
in-embedding caching, etc.  The GCLS results should, IMO, be interpreted
as "no data available for the Mozilla JS engines", and not be taken as a
general description of the JavaScript language's "inherent performance".
(You'll find, f.e, that the IE engine/Windows Scripting Host has very
different performance characteristics in real applications, due to its
different GC design and implementation atop the COM layer.)

(Even within the "Mozilla JS engine" family, performance varies
tremendously between Spidermonkey -- C engine, generates internal
bytecode -- and Rhino -- Java engine, can execute the parse tree for low
compilation overhead [eval() cases, f.e.] or generate Java bytecode for
execution under the JIT running the rest of the application.  And I, at
least, found some of the variation quite surprising, even having worked
on both engines in a variety of environments.)

Conservative, to me, is making careful analysis of your performance
requirements in the large, and finding a tool -- be it a language
runtime, a database subsystem, a rendering engine or a networking stack
-- that matches your requirements most closely.  That's a fair bit more
work than reading the GLCS, though, and sadly most people don't do it.

Again, I want to mention that I won't object to someone choosing another
scripting language; for many applications, JS is likely not appropriate,
and if I were to be offended at use of other languages I'd already have
died of shame under the burden of the billions of apps embedding python
and lua and guile.  I just want, likely for the last time, to point out
why I think that you -- and others, no doubt, you're just the one brave
enough to post about it -- are likely doing your application a
disservice by relying as you seem to be on a single (unrelated, in fact)
data point for the analysis of something that is, by your own admission,
critical to the quality of your software.

> I'm not close minded about it, but 
> when looking for docs on Ruby, Python or Lua they are far more 
> abundant (at least when it comes to embedding, not on the languages 
> themselves).

I don't know what sorts of embedding docs you're looking for -- it would
not surprise me to discover that there are more for those languages,
though, as they enjoy a wider "open" developer community -- but you
might find the various embedding guides linked from here to be useful:

http://www.mozilla.org/js/spidermonkey/

It's hard, it turns out, to get good google juice for "Javascript
Embedding", though "Javascript Engine Embedding Docs" has this as its
first hit:

http://www.mozilla.org/catalog/libraries/js/

> > http://www.xulplanet.com/, in case you care again in the future.
> 
> Been there, done that, didn't exactly help. =|  XUL is the 
> language/schema, but it's not clear what its relationship is to XPFE, 
> and how to embed XPFE (or even what the hell it really is).

Oh, XPFE isn't designed at all for embedding other than by embedding all
of Gecko, and I doubt it will become so.  There are other XUL
implementations out there (at least one, anyway, done to marry XUL and
Swing) that are more amenable to application-neutral embedding.  It is
almost certainly not the droid you're looking for.

Mike