[MUD-Dev] MUD Design Fundamentals (Was: Looking for

Jeff Kesselman jeffk at tenetwork.com
Sat Aug 30 22:11:59 New Zealand Standard Time 1997


At 09:48 PM 8/30/97 PST8PDT, you wrote:
>>A relational database really is just a way of organizing data on the disk
>>drive.  The inetrface coudl be what you describe or a standard table-type
>>generic inetrface.  In either case a dataabse coudl be living under neath
>>to ragnize the data.
>
>Well, databases as such are typically shared among many clients, and that
>is their design rational.  They are typically accessed by batchlike
>functions (at least conceptionally).  I think there is a big difference

No, sorry.

A database sevrer does this.  But Cold for instance is absed on ndbm which
is a full data base library that is linked directly to your code and uses
individual fiels per application.

What your are describing is a implementation feature of a partoicualr
applciation of an rdbms-- that of an rdbms server.

>
>>cold or Smalltalk) do NOT require such an active effort.  In genral the
>>difference is in tehcnase of cold or Smalltalk the persistance is built
>>into the system, in the case of a C++ persistance library it is an add on.
>
>Well, I agree, that the ideal situation would be to have persitance as a
>part of the language design specs.  I still don't see how you can ignore
>realtime information, UNLESS the language is dedicated to the task at hand.
>I still think that changing the object-system (design) requires a wipe
>unless you go through a lot of trouble to avoid it, if you use persistent
>features.

No, it does not.

You need to loo at small talk and/or Cold.  I already treid to explain how
you stoire the structure of an object within an rdbms.  I am afraid if that
failed I can't think of how to make it any clearer.  EVERYTHIGN n a
computer is ultimately data, even code and the sstructure of your data.
Itc an be amde as hardcoded or as flexible as you wish-- ist up to you.  

>
>Anyway, for all practical purposes, I think C++ or other OO languages
>decending from ALGOL/SIMULA was implied here.  I care about control and

Well, OO was really first fully developed as a cocmept with Smalltalk.
Frankly I think in the case of C++ (I havent done Smalltalk) youa re
talking "Object DEesign" languages as oppseod to true "Obejct oriented"
languages.

There IS a difference, a fudnemental one, and its very hard to decroibe to
someoen who hasnt worked with the latter.


>My main point was that persistance isn't neccessarily going to save your
>butt, although it "sounds like magic".  I would at least go for secondary
>backup functions that store information in an easily parsable format for

Thats a totally different issue. NOTHIGN repalces the need for backups.
period. The end.

>saving and loading the most essential information.  If not, you are
>probably stuck with your initial design, or have to accept more clean
>wipes than you like.

But THIS is incorrect.

JK

Jeff Kesselman
Snr. Game Integration Engineer
TEN -- The Total Entertainment Network -- www.ten.net

-----BEGIN GEEK CODE BLOCK-----
     Version: 3.1
     GCS/CC/E/IT/MC d+(++)@ s: a C++++$ ULSC+++(++++)$ P++(+++)$ L++ 
     E--- W++$ N++$ o+ K--? w++(+++)$@>--- O+(++)>$ M+>$ !V PS++ PE+ 
     Y+ PGP- t+ 5+ X- R+(++)$>+++* tv+ b+>++ DI+++ !D G e++ h r+++ y+++
------END GEEK CODE BLOCK------ 

Speak Geek!
http://krypton.mankato.msus.edu/~hayden/geek.html



More information about the MUD-Dev mailing list