MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: Cold (Re: wish-list)

On Wed, 21 Aug 1996, Gustavo Glusman wrote:
> Brandon wrote:
> >Or you can just use Cold <...>
> >(BTW, the cold driver is stable--it is currently running several dbs,
> >including one db with about a 27MB db (this is the compressed binary
> >db)--this server runs in about 6MB RAM; there should be a ColdCore release
> >soon)
> 
> Cold sounds really exciting, promising and delivering. Can I assume safely
> that there will be an easy way to make the move from MOO to Cold, without
> having to start from scratch?

No, the language (ColdC) is advanced and abstracted much more than MOO.  
It _IS_ possible to convert MOO to ColdC (ftp://cold.org/cold/moo2coldc/gz)
the conversion is not complete, due to the complete lack of encapsulation 
in MOO and the complete encapsulation in cold.  A raw conversion also 
does not take advantage of the additional data types and differences in 
data types (differences as in regexps and binary data).

> Note that a ColdCore means starting from
> scratch, if an existing MOO database has to be simply trashed because it
> cannot be transferred without some good measure of automation.

A topology convertor has been discussed.  This would basically dump a MOO
db's physical aspects (rooms, things, etc) to a command-line format that
can simply be pasted into the cold system.

> I agree that, if we were to start everything again from zero, we might be
> much better off using Cold. But consider a MOO with hundreds of users and
> thousands of objects, with a relatively lean database thanks to selective
> diskbasing (read FUP), and running on a machine that is quick enough that
> the average server lag is zero. Our main problem is the netlag, and this is
> one bug that Cold won't fix.
> 
> So, why should we move to Cold?

This is true, and for some systems they may wish to stay with MOO. 
However, when you run a Cold server on the same hardware you will likely
be able to have two to three times as many people connected and active
before you hit limitations (as far as interpreting goes).  Basically, if
LambdaMOO (the VR@parc) were written in Cold from the beginning I doubt
there would be any lag concerns right now. 

Cold's inherent disk basing is also an advantage, as you dont have to let
your db swap out, and asyncrynous binarydb backups are a definite win (no
forking, and only a slight pause as the cache is flushed to disk). 

I ran a MOO a few years ago, for over a year.  We did a large amount of
core changes and building.  However, after I was introduced to Cold and
the full immensity of Cold hit me (even back in those days) I dropped the
MOO db on its feet.  In retrospect it was like trying to thrive in a
stuffy room, only to have somebody open a window to the lush open world
outside, full of possibilities ;)

Getting back to my original point, I would not suggest most existing MOO
databases convert.  However, the amount of database changes required to
integrate some of the more desirable aspects of Cold into MOO would
involve a much larger effort than simply converting to Cold.  I'm speaking
from experience, I had to upgrade the core every time I or others added a
new desirable feature to Cold--fortunately Cold textdumps are in a human
readable format :)

I also think people would be happier using Cold instead of MOO for many of
the roles MOO is starting to take, especially on the web.  For a full
example of the ability of cold, go to the following web site.  It is a
HTTP 1.0 server (supporting both POST and GET) which dynamically generates
custom pages for the client, handles an asyncrynous 'shopping list', and
is written entirely in about 2000 lines of ColdC code.  It pulls its
information from a relational PROGRESS database where inventory and
ledgering is handled. 
 
    http://www.sunrem.com:1234/

If anybody wants to discuss more possibilities, connect to 
ice.cold.org:1138 as 'guest YOURNAME YOUREMAIL' and I (or others) 
would be more than happy to talk 8)

-Brandon Gillespie-
References:
Home | Subject Index | Thread Index