<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] UM2 -->
<!--X-From-R13: "Uert [hag" <tertNhav-pbea.qrzba.pb.hx> -->
<!--X-Date: Tue, 15 Jun 1999 21:31:58 -0700 -->
<!--X-Message-Id: 001b01beb77c$c20b49e0$15b8989e@ztkrzijb -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] UM2</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:greg#uni-corn,demon.co.uk">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00822.html">Previous</a>
| <a href="msg00824.html">Next</a>
]
Thread:
[ <a href="msg00861.html">Previous</a>
| <a href="msg00822.html">Next</a>
]
Index:
[ <A HREF="author.html#00823">Author</A>
| <A HREF="#00823">Date</A>
| <A HREF="thread.html#00823">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] UM2</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <<A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A>></LI>
<LI><em>Subject</em>: [MUD-Dev] UM2</LI>
<LI><em>From</em>: "Greg Munt" <<A HREF="mailto:greg#uni-corn,demon.co.uk">greg#uni-corn,demon.co.uk</A>></LI>
<LI><em>Date</em>: Tue, 15 Jun 1999 23:15:55 +0100</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
Something that may be of interest - a mud being implemented, using
Smalltalk. The 'UM' is derived from UglyMUG - a direct TinyMUD descendant,
and the direct parent of the mud that I used to manage. There seem to be
many references to that mud ('The Chatting Zone', or 'TCZ') on the UM2
website.
Trivia: I met Ling's brother on UglyMUG. His unique online persona has had a
definite influence there - witness the Griz socials, and even the GrizBot...
From <A HREF="http://www.uglymug.org.uk/um2/bspec.html">http://www.uglymug.org.uk/um2/bspec.html</A> :
------
Base Specification
Document version: 0.04
Current maintainer: Splange
Last modified: 1998-12-20T16:31Z
Table of contents
1 Revision history
2 Introduction
2.1 What is the Base?
2.2 The four-layer model
3 What functionality does the Base provide?
4 The reference platform
5 The Base components
5.1 Connection Manager
5.2 VM Manager
5.3 Security Manager
5.4 I/O Manager
5.5 Config Manager
6 Implementation notes
1 Revision history
0.04 Various changes to reflect the choice of Smalltalk as U-Code language
and Base system. The four-layer model changed slightly. Some notes on
implementation added.
0.03 Reference platform info added.
0.02 HTMLised and edited slightly.
0.01 Compiled from UM2 list traffic.
2 Introduction
2.1 What is the Base?
The Base is the primary component of UM2. It provides the framework for the
rest of the system to exist and at the same time insulates the system
against the specifics of hardware, operating system, network protocols, and
terminal emulation.
UM2 is intended to be as generic as possible. Therefore the Base - the bit
that's hard to change - contains the minimum 'business logic' - that is, it
contains as few design decisions as possible about the total system and how
it appears to the user. To take an example, the business logic of how rooms
link up with one another, or even what rooms are, is unknown to the Base. It
provides facilities for manipulating and storing objects - if you decide to
call them rooms and do room-related stuff with them at higher levels of the
system, that's up to you. The Base is supremely indifferent.
Of course at some level in the system we have to put in some business logic,
or the result would be a grey world of featureless objects that do nothing,
like an airport departure lounge. The Base provides a language to code this
logic in: U-Code. The only way to access the low-level Base components is
via this U-Code interface - or to put it another way, the interface between
the Base and the rest of the system is U-Code.
This generic nature of the Base means that it can be used to implement
worlds as diverse in look-and-feel as a straightforward talker, an LP-style
hack'n'slash MUD, an Internet conferencing system or even something closely
resembling UglyMUG Classic - without even recompiling the Base.
2.2 The four-layer model
To make things a little easier to work on we have divided the system into
four conceptual layers.
Layer 1: Base
This layer consists of the system server code, responsible for such things
as handling network connections, talking to the DBMS, and the U-Code virtual
machine. It provides a mechanism for users to interact with the 'world' (the
universe of UM2 objects). All the layers above the Base are implemented
inside the world itself.
Most of these services come free as part of the Smalltalk VM, so the Base
contains little UM2-specific code.
The Base is common to all UM2 systems.
Layer 2: Core Objects
While the Base provides all the services necessary to construct a multi-user
world, the Core Objects layer actually implements it. For example, in a
UM-Classic-style system, the Core Objects layer might provide:
Player, Room, Exit, and Command objects and their associated logic
A set of standard library objects
A single room instance and privileged player instance which users can use to
construct new worlds and create new players
The Core Objects layer differs between UM2 systems designed for different
purposes - for example, three different Core Object sets might define three
different applications: a simple talker, an Internet conferencing system,
and a role-playing game system.
Layer 3: Worlds
The third layer comprises the virtual worlds built using the Base and Core
Objects layers. For example, a typical talker-style world might have ten or
twenty connected rooms and a hundred avatars, together with various useful
objects such as a bulletin board system and a way for users to send mail to
each other.
The system's users
The rooms and other objects making up the particular world
Useful objects and code libraries developed in-world
The Worlds layer is different for every UM2 system because it is developed
by and for the particular set of users that a system has.
Layer 4: User
This is the layer where the user actually interacts with the system by
entering commands and receiving output. This is achieved by using a
'shell' - a generic name for any interface allowing user input and output.
The basic shell provides simple command-line style interaction, but
additional shells could provide a more graphical UI - for example a Java/Web
interface.
The commands the user types may be implemented in U-Code, U-Script, or
scripting language X. Neither the user nor the shell (or for that matter,
the Base) cares which.
3 What functionality does the Base provide?
TCP/IP connection services to allow users to connect to the system and
interact with it.
Services which allow the rest of the system to manipulate objects without
caring how or where the object data is physically stored.
A virtual machine which executes U-Code programs.
Security services allowing fine-grained object access control.
An Input/output module which abstracts details of the user's connection such
as the terminal emulation protocol being used.
A configuration module which stores and provides access to system
configuration information.
4 The reference platform
Although the Base is designed to be portable, grouping platform-dependent
knowledge into loosely-coupled modules, there has to be something to port.
The following reference platform is specified:
Architecture Intel
OS GNU/Linux
Smalltalk VM Squeak
5 The Base components
5.1 Connection Manager
A daemon process that listens on a specified port for incoming user
connections, handles them when they happen, monitors disconnections and
provides connection-related services to the rest of the system.
5.2 VM Manager
This component exposes the virtual machine on which U-Code runs, and
therefore implements the U-Code specification. It provides facilities for
threading, scheduling, locking and all those good things.
5.3 Security Manager
It makes sense to draw all the security-related services together in one
place, and here it is. The Security Manager provides services such as
authenticating users to the Connection Manager, and all user access to
objects will go via this module.
5.4 I/O Manager
The I/O Manager handles all the details of user session input/output, knows
about things like Telnet protocols and terminal emulation, and may also
provide other interfaces to the outside world such as serialising objects
over a link to another UM2 system or dumping objects to disk.
5.5 Config Manager
This module is responsible for storing and providing access to system
configuration information. As many system parameters as possible can be
changed while the system is running, and the Config Manager provides a way
to do this, as well as responding to requests for information about the
system's current configuration. Nobody else but the Config Manager cares
whether a piece of information is stored in the database, read from a text
file or supplied on the server command line.
6 Implementation notes
The Base is implemented in a Smalltalk system as a single, 'core' image,
comprising the Base components plus a minimal set of Layer 2 objects. This
image is distributed as the basic system, together with a set of sample
world images which make up prefabricated MUG environments.
In a production system, the Base and its corresponding world are combined in
one image file, which is snapshotted to disk at configurable intervals. This
means that the entire UM2 system comprises simply the Smalltalk VM
executable and the monolithic world image.
------
Greg.
_______________________________________________
MUD-Dev maillist - MUD-Dev#kanga,nu
<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A>
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00822.html">[MUD-Dev] Fwd: Books on Compilers</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00824.html">Re: [MUD-Dev] Game Economies</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00861.html">Re: [MUD-Dev] Properties of computer languages</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00822.html">[MUD-Dev] Fwd: Books on Compilers</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00823"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00823"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] Properties of computer languages</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00848" HREF="msg00848.html">Re: [MUD-Dev] Properties of computer languages</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Fri 18 Jun 1999, 01:40 GMT
</LI>
<LI><strong><A NAME="00851" HREF="msg00851.html">Re: [MUD-Dev] Properties of computer languages</A></strong>,
David95037 <a href="mailto:David95037#aol,com">David95037#aol,com</a>, Fri 18 Jun 1999, 14:19 GMT
<UL>
<LI><strong><A NAME="00859" HREF="msg00859.html">Re: [MUD-Dev] Properties of computer languages</A></strong>,
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Sat 19 Jun 1999, 03:16 GMT
</LI>
<LI><strong><A NAME="00861" HREF="msg00861.html">Re: [MUD-Dev] Properties of computer languages</A></strong>,
Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Sat 19 Jun 1999, 18:00 GMT
</LI>
</UL>
</LI>
</ul>
</LI>
<LI><strong><A NAME="00823" HREF="msg00823.html">[MUD-Dev] UM2</A></strong>,
Greg Munt <a href="mailto:greg#uni-corn,demon.co.uk">greg#uni-corn,demon.co.uk</a>, Wed 16 Jun 1999, 04:31 GMT
<LI><strong><A NAME="00822" HREF="msg00822.html">[MUD-Dev] Fwd: Books on Compilers</A></strong>,
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Tue 15 Jun 1999, 21:38 GMT
<LI><strong><A NAME="00818" HREF="msg00818.html">[MUD-Dev] ADMIN: NoMail Subscriptions -- please reconfigure</A></strong>,
J C Lawrence <a href="mailto:claw#varesearch,com">claw#varesearch,com</a>, Tue 15 Jun 1999, 03:20 GMT
<LI><strong><A NAME="00816" HREF="msg00816.html">[MUD-Dev] speed problems update</A></strong>,
Matthew Mihaly <a href="mailto:diablo#best,com">diablo#best,com</a>, Mon 14 Jun 1999, 23:14 GMT
<UL>
<LI><strong><A NAME="00817" HREF="msg00817.html">Re: [MUD-Dev] speed problems update</A></strong>,
Quzah [softhome] <a href="mailto:quzah#softhome,net">quzah#softhome,net</a>, Tue 15 Jun 1999, 01:19 GMT
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>