# Cold (Re: wish-list)

Brandon Gillespie (brandon@tombstone.sunrem.com)
Wed, 21 Aug 1996 18:52:16 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    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-