MUD-Dev
mailing list archive
[ Other Periods
| Other mailing lists
| Search
]
Date:
[ Previous
| Next
]
Thread:
[ Previous
| Next
]
Index:
[ Author
| Date
| Thread
]
Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for
- To: mud-dev#null,net
- Subject: Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for
- From: Ola Fosheim Grøstad <olag#ifi,uio.no>
- Date: Sat, 30 Aug 1997 18:14:03 +0200 (MET DST)
>A relational database really is jsuta way of organizing data on the disk
>drive. The inetrface coudl be what you describe or a standard table-type
>generic inetrface. In iether 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
between this and a realtime system where there is a timeline involved.
And for any reasonably sophisticated system the system state is related to
realtime information (system clock, network connections etc). I have
problems seeing how any MUD system can ignore the distinction between
statevariables that are valid and consistent between runs, and those that
are not.
>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.
Anyway, for all practical purposes, I think C++ or other OO languages
decending from ALGOL/SIMULA was implied here. I care about control and
efficiency, I believe other developers do the same.
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
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.
Ola.
- Thread context:
- MUD Design Fundamentals (Was: Looking for books...), (continued)
- MUD Design Fundamentals (Was: Looking for books...),
Ola Fosheim Grøstad olag#ifi,uio.no, Thu 28 Aug 1997, 22:16 GMT
- Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for books...),
Jeff Kesselman jeffk#tenetwork,com, Thu 28 Aug 1997, 23:45 GMT
- Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for,
Ola Fosheim Grøstad olag#ifi,uio.no, Fri 29 Aug 1997, 10:46 GMT
- Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for,
Jeff Kesselman jeffk#tenetwork,com, Fri 29 Aug 1997, 18:54 GMT
- Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for,
Ola Fosheim Grøstad olag#ifi,uio.no, Sat 30 Aug 1997, 16:14 GMT
- Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for,
Jeff Kesselman jeffk#tenetwork,com, Sun 31 Aug 1997, 05:10 GMT
- Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for,
Jeff Kesselman jeffk#tenetwork,com, Sun 31 Aug 1997, 05:27 GMT
- Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for,
Ola Fosheim Grøstad olag#ifi,uio.no, Sun 31 Aug 1997, 12:02 GMT
- Re: [MUD-Dev] **sigh** OOP wars and defining RDBMS,
Jeff Kesselman jeffk#tenetwork,com, Sun 31 Aug 1997, 19:36 GMT
[ Other Periods
| Other mailing lists
| Search
]