Advanced Topic - Doing it differently.

Hiddukel hiddukel at rebeldev.net
Tue Apr 5 15:41:32 New Zealand Standard Time 2005


-----Original Message-----
From: Christopher Bunting [mailto:cbunting99 at gmail.com] 
Sent: Monday, April 04, 2005 10:16 PM
To: Hiddukel
Cc: rom at rom.org
Subject: Re: Advanced Topic - Doing it differently.
-- snip --
If you can implement mysql into the mud, I would think it'd be a snap
tp write the simple lines of c code to parse the output of the log
file and output it to the web? Heck, you could just have the mud
output each log each day directly to a formatted html page.. There's
been a mud log program out for years that will read it in and generate
html. Doxygen can read mud help files and output them via html for the
web.. So can help2html. Everything and every reason I've heard for
using mysql can be done without it..

 Write a simle web server built right into the mud to show the output
of the exported html from logs, helps or whatever..
 
 Example:

 void server(void)
{
    int sock = sockopen(NULL, 8100);
    unsigned char info[6];
    if (sock == -1) {
        perror("server.sockopen");
        exit(1);
    }
    sockinfo(sock, info);
    printf("Server socket open on host %d.%d.%d.%d, port %d\n",
           info[0], info[1], info[2], info[3], info[4] * 256 + info[5]);
    socklisten(sock, handler);
}

 Maybe I really am missing the point.. As I said, all the other
options just make more sense to use over mysql.. But that is only my
opinion so if it works for you.. Thats awesome..
-- snip --

You did miss the point about this ... the point was the "search" part of it.
Yes outputting the log file to html is easy and the search is not even that
bad using C, but C is also not a scripting language, it is a compiled
programming language.  What I was getting at is that an sql (note my use of
sql here and not mysql, not all databases are as easily corrupted as mysql
is) database is not only easily accessed by the mud, but also by other
sources, something that a flat file system (like the one currently in use by
rom, because if you are going to change the entire format why bother staying
with flat file, even if it is Berkley db flat files?).  On the subject of
overhead by the way, the same argument could be used for threading, that
muds have run forever without it, but the fact is muds are getting bigger
and some have functions that do take a while to run (like massive searches
through thousands of pfiles) if you use an sql database on a separate server
from the mud itself then you are effectively moving the load of these
searches off of the machine the server is on so resource intensive functions
do not affect the performance of the mud, regardless of how many players are
logged on.  I'll give you an example though, try adding 400,000+ rooms to a
rom mud (with the addition of long vnums and ivans olc) and do an asave
world and see how bad it lags the mud, then try doing the same thing using a

thread and a database on a different machine.  Major difference.

And not to beat a dead horse or anything but to quote you "General muds have
worked great for years and there was never a need for this back in the mid
90's..".

We also used to use 2 digit years with no problems, that didn't make it
anymore right when y2k came around though did it?

-- 
ROM mailing list
ROM at rom.org
Unsubscribe here ->>> http://www.rom.org/cgi-bin/mailman/listinfo/rom


More information about the MUD-Dev mailing list