Number Name Description
------ ---- -----------
#0 The 'root object' which holds the $ properties and the
system level verbs (do_command, user_connected, etc)
#1 The 'root class' from which all other base objects are
descended
#2 $command_mode The storinghouse for the lily command set (both user
and admin); no valuable properties are located here
#3 $admin The owner of almost all lily verbs; this negates any
permissions structures in the lilyCore. This is
considered to be one of lily's design flaws and the
target of the fourth lily rewrite. This object also
holds onto the programmer/wizard @ verbs.
#4 $string_utils This Maker object holds verbs to do operations on
strings or transforms complex lists into strings.
#5 $code_utils Many of the verbs called by the @ verbs for programmer
issues reside here. This is also where errors are
transliterated into cool messages.
#6 $player At the very center of lilyCore's design is the player
object. It contains all of the properties and verbs
necessary for most player-player, player-disc, and
player-game interaction. The player object even parses
its own commands. Every user account is direct descended
from $player.
#10 $disc The discussion object manages the state and permissions
for discussions. All existing discussions are children
of this object.
#115 $client Much as users have their own player object, clients from
'consult' have their own object. This object holds state
for the client and does command interpretation.
#158 $event_mgr ... ?Ach?
#384 $sset This object implements a fast-string matching algorithm
that Maker ?invented?. It works by breaking the string
into two character substrings and using those to
reference a hash bucket. The search space is cut down
quickly and easily.
#388 $sset_p The child of $sset that manages the user namespace.
#437 $helper This object is the hack done for Prisoner's WWW hyper-
text help page.
#445 $lily_utils This object holds the utility functions for lily, so
the player object doesn't get overloaded. It also acts
as a catchall for properties which are needed to speed
up lily commands.
#497 $list_utils This object holds list management utilities like match,
sort, merge, and scalarSort.
#502 $review_mgr ... ?Ach?
#503 $sset_c The child of $sset that manages the command namespace.
#714 $game The parent object for all games. It implements a
suggested set of game verbs and hold the default game
properties, but it isn't clear it is valuable.
#767 $help_mgr The new help subsystem. It manages the help command set,
and help indexes and database. The help is stored as
a list of help words then at the same offset in the
database is the text for that help.
The action-flow of lily for the typical user is actually fairly simple,
though it has unique twists and turns significant to MOO. The first stage
is actually one of Maker's original hacks. When a user connects to a MOO
it calls #0:do_login_command() and passes it whatever the user types, the
first invocation the parameters are {} (the empty list, or no parameters).
The server displays a welcome message whenever that occurs, which is why
you see repeated welcome messages if you hit <Return> at the login prompt.
Each time you supply information (login or password) the verb calls
#0:get_login_state() and #0:set_login_state to record the progress of your
login. There are special cases in the code for Prisoner's WWW hack and
consulting. Just as a cheeky note, pay attention to the character at the
end of "Login in the wrong" it actually secretly tells you what was wrong
with the login attempt. ;) Once both login and password are complete and
correct the verb returns the object number of the user associated with
that login/password. Until we return a valid object number MOO will regard
the connection as only partially logged in.
Now that the #0:do_login_command has returned a valid user object, MOO
continues on its way. If the object is _already_ connected then the other
instance is told it has been redirected away and #0:user_reconnected() is
called. That verb just forces the user to "detach by accident", though
their connection is never dropped, and calls #0:user_connected. In this
way we have made redirecting a more useful concept in lily terms.
Regardless, #0:user_connected is called and the user object is passed as
argument one. If user is a client, then the client object's confunc() is
called and the verb returns. Normally, however, the verb proceeds showing
the banner, last login, and voting status. Then it called the player's
confunc() which sets the name and blurb (though more verb calls), changes
the user's state, updates the state caches, and announces the user's
presence on the system. Back into the #0:user_connect verb we go,
welcoming the user to lily. Then, if appropriate, we join the user to the
default discussion and join them to any discussions they were in if they
"/bye"ed.
At this point the user, WWW hack, and client merge paths again as both
have all their commands interpretted by #0:do_command (this is a MOO
necessity). lily simply passes through #0:do_command for performance
reasons and calls the object's version of the do_command verb. The
performance concern was that #0:do_command used to be _terribly_ complex
because it special cased admins, programmers, the WWW hack, clients,
regular users, etc... It was TERRIBLE! The solution was to take a logical
backstep and allow the object itself to manage parsing, visible
command-set issues vanished. Now there is no concern that something will
go wrong and clients will get regular lily commands since _their_ parser
would know how to invoke them. :) We reuse the $sset data structure for
command parsing since it delivers a ten times performance increase over
the old method of parsing.
Since it is now time to go. I'll stop here. Tomorrow I will pick up with
an indepth look at parsing, messaging, and the player object.
later,
christian
-----------
"You shouldn't have took more than you gave, | Christian Ratliff
and we wouldn't be in this mess today. | <ratlifc@ctron.com>
I know we've all got different ways, | Cabletron Systems
but the dues we've got to pay are still the same" | MIME and NeXTmail ok