On Fri, 2 Apr 1999, Michael Lemler wrote:
>To include a bunch of native database driver support for the mud would be
>insane.
Not really, the MySQL code required to load a zone file out of the
database with comments and such in the code is only 165 lines.
>Each one usually has it's own API, so each line of code you
>generate has to be proprietary to the database system.. unless you write
>your own preprossesor.
Object Abstraction. To the MUD, the database is a void * token. To the
database parser it is a description of what database to go ask. To the
high-level database structure it is how to interpret the request. Then the
lowlevel database driver just fetches and returns data without caring what
it was.
All of the SQL-like databases should be able to share the same upper level
database if no extensions are used.
>Future exapandablity is also hurt, simply slapping some defacto libs out
>there for DBMS systems out there now, won't solve the issue of another
>system out there who only supports ODBC (where everything is going).
>ODBC is fast enough to do what MUD design had in mind. ODBC is fast
>enough for enterprise wide applications. I just don't see the value of
>adding proprietary code when you can simply have "one size that fits all"
>and compatability.
I coded up the MySQL module according to their C API. I'll probably have
individual database drivers (though I'd hardly call them drivers based on
what I plan to do) for those I have access to and a generic ODBC driver for
people to use on databases I don't have.
--
George Greer | Mailing list archives
greerga@circlemud.org | http://post.queensu.ca/~listserv/wwwarch/circle.html
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST