NMC Project - Server Issues

NMC - Server
Issues

Otter: Outlook on List-management Library

From Otter, 03-28-01 on NMC Dev:
OK, this describes what the new list-management library will need to address.
For those who don't know, we've got a new set of libraries in the NMC that are about to replace many of the old undocumented libraries. This new set was designed from the ground up with the following idea:

libraries are organized in levels, with a lower-level library never calling a higher-level library

lower-level libraries provide system behavior, higher levels provide application behavior.

Yes, you who have studied OO recognize this as a base-class/derived class concept, where the 'base libraries' provide what is shared to the derived libraries. Also, this is clearly stealing from the layered protocol approaches as used in the OSI and TCP/IP models.
The other issue we've been focusing on is keeping the interfaces documented. If you skium the code in the new libraries, you will find the ration of code and comments to be MUCH higher in comments than any of the old libraries. Thus, its not enough to have the libraries, we want them to be called properly and easily.
To this end, we've been focusing on things such as error string management and use string management by making a string management library (in Windows terms, a 'string table resource'). We've been focusing on end-users with MPI being able to access safely the library functions that will let them build their own versions of the top-level commands, without security breach. And we've got that docuemented as well.
The server now handles $regname[:[:]source] syntax, which allows recursive sources. Thus, this is a legal reg-name: $myroom:$db-object:*otter. It means "Seek _reg/myroom on the object _reg/db-object points to as defined on *otter". Woof! But, that's all in the server. Its consistent, and its fast. Very fast. The old 'match' macro to a library call is going away.
We'll document the hierarchy of libraries, as a hierarchy, with rationale, soon. Its actually sitting on a white-board in my office right now. It is formally expressed. I'm not in my office, or I'd key it here and now for you. Perfect? Heck no...but its a MUCH nicer start than the ball of twine we currently have.
OK, that's said...what about this list library.
I've said this in prior emails, but this email I think will end up on the web-site, so I'm going to say it again...as a review, and to make sure that its clear in all our minds.
First off, the lists involved in this discussion are lists of characters (meaning players and zombies). Could this be used for rooms or exits? Possibly, probably. But, since we're going to make something small that works, and extend later, for now, this is going to focus on characters.

A list can be one of three types:

controlled list
This list is controlled by a lock, and anyone who passes the lock can add or remove any character to the list. The character needn't want to be on the list, and can't request to be removed. Such a list is used for the following reasons:

page ignore

watchfor

permissions of who can enter a room

a list of who can not enter a room

Thus, this is the list that for now is hard-coded in so many programs in a proprietary way (often as a space-seperated string such as page uses).

member-controlled list
This sort of list is un-managed. Anyone can add or remove themselves to it at any time. Nobody (unless they pass an admin lock) can add another to such a list. This type of list is used for:

public chat-channel memberships

people who want to get notified of events

voting

This list lets us avoid mass-pages and spamming those who don't care about what we want to say, while letting those who do opt out if they wish. In short, this is what an RL email-based mailing list does.

Agreement list
This list is what +skills currently does. You have to apply to join it, and that application must be approved. This last can further be divided into two categories: opt-out and removal-based. An opt-out list means that I can quit if I wish. Removal-based means that only the granters can remove. +skills is currently a removal-based list. The reason this is not truly broken into two full list types is that the opt-out can be specified as a lock... and thus the list can be customized instead of hard-coded in the library.
This list is primarily made for membership of private groups, and would be used the exact way +skills currently is.

So, those are the three types of list. +list currently does controlled lists, and +skills does agreement lists. Nothing does member-controlled lists.
Its not enough to manage the lists. First off, there needs to be an easy way to find the list. Some lists should have global names, some should have names that are restricted to a region. In short, we need a better naming scheme than "+skills #list" which is a total chaotic garbage mess. And we need a way to indicate that we're using a named list. And we need a way to lock to list membership, or not to list membership.
Secondly, there needs to be a way to determine what additional data a list holds besides membership. One of the main benefits of things like the staff programs everyone has been writing on their own is that it not only who holds, but in what area they work, their rank, etc. A list, therefore, needs to allow the list manager to specify what data is held in addition to the list, and who can change that data. There needs to be easy ways then to view, change, and remove such data.
Lastly, the existing programs need to use these lists instead of their internal lists. @help, for instance, should have a name of a list it checks for a given region. NOT '@help #add' but a list managed by +list. Page should have a few lists: ignore, priority, alias. There's no reason the same list used for page priority can'e be used as the 'wf' watchfor list. And no reason that list also can't be used in the 'jump-to-me' lock. And... you see, if all our programs use the same list-manager library, then any list we build can be used in any program we run.
And the users will need to learn exactly one way to join a list, and they won't need to learn 'page #ignore name', '@help #add region=name', etc., etc., etc.
Of course, they will complain, "But, its too hard." Even though they do less typing, and use fewer commands, than they did before.
And, as before, we'll show them how and why. Redwall seemed pretty excited by what they could do this morning... because Nameless MUCK took the beating of testing the stuff out. Naturally, we won't upgrade other MUCKs to these things until we know them, they work, and we've got some docs.
Right?
Keep the Light,
Otter

Posted on Saturday, April 28, 2001, by Romaq (Scripts)

Otter: New worlds, yours or your players?

From Otter, 03-11-01 on NMC Discussion:
Something all MUCK creators should think about...
If only staff builds the world initially, the players will be visitors in your world. If you get players and let them build the world, then it will be their world.
Redwall MUCK opened with something like 30 rooms. And we got players building as quick as we could.
Remember, players are very creative and want to be a part of things, not silent observers of things. That's why they always ask for things to happen.
Keep the Light,
Otter

Posted on Tuesday, April 24, 2001, by Romaq (Scripts)

Otter: Logfile looks ahead

Note from Romaq: This was over the nmc-dev mail list. A reminder to the uninitiated, we are real people involved in a creative process. If this is a problem... consider doing a word search on open source code including the Linux kernel.

From Otter, 03-15-01 on NMC Dev:
Badger, Romaq, and I were talking on the staff channel of Nameless today, and I thought this log was a good way to show the kinds of things we're trying to do, since I was trying to get an idea of what to document.

Its not very long (139 lines long).

Start log *****************************
Otter says, "OK, about +tune...how do we want it to work?"
Otter says, "I've no problem if +tune sets/shows @tune values as well. I am not sure I'm going to keep @tune >:)"
Otter says, "I damn near pulled it out when I was in Vilnius."
Badger says, "Having them all property based? I don't see why not."
Romaq says, "No arguement from me. Bitch should be on #0."
Romaq says, "Or however we are storing those with +tune"
Otter nods. "+tune ought to let us say what prop on what object, and human-readable meanings and help for the props. Is that what +tune does?"
Otter says, "Or, is +tune storing all on a single 'registry'?"
Badger says, "+tune was originally designed to set the settable settings on lib-settings >:P"
Badger says, "Since there were hundreds of them."
Otter says, "OK, then perhaps a re-think is in order..."
Badger says, "It grew to allow settings on any program, though."
Otter says, "What if +tune is a list in one place of sub-categories entries, where each entry describes a prop-name, an object, possibly a MUF called to validate a new setting, and help?"
Badger says, "But they were all stored on +tune.. the 'tune settings' that is. eg: default_player, uses prop "/default-player" on "$~cmd/chars"."
Romaq says, "One of my bitches with @tune, besides spam-hell, is the category issues... related things are not together, and there is no 'big picture sense' to it, as well as the dearth of documentation."
Badger says, "Minus the validation, that's how it is setup, I believe."
Otter ponders.
Otter says, "With +tune, then, we would have one place for all program settings that aren't locks, and +lock #admin is one place for all program settings that are locks?"
Badger says, "None the less, it'd probobly need a rewrite. Or some massive makeover. It was written when I was writing lib-settings, there abouts.. so the code is likely, to say the least, awefull >;P"
Badger says, "+lock #admin and +tune would pretty much cover everything, I believe."
Otter says, "And have we talked about hooks?"
Badger nods. "That's not lock or tune assisuated, though. Unless they have their own hooks. Which +tune could. (Group chat: staff)
Romaq says, "Like +dispatch type hooks?"
Badger says, "Like the validation ccalls."
Badger says, "assosiated, oye."
Badger says, "Not that that's probobly right, either. But at least readable."
Otter says, "I gave an example of hooks in an email yesterday or the day before. I thought, Badger, that you and I talked about them over lunch at Mr. Kims ones."
Otter says, "Once. Sheesh."
Badger nods. "We did. Lots of programs could use them... but they've not been implimented.
Romaq says, "Oh yeah... the hooks for lock testing."
Otter says, "Oh, I know they aren't implemented."
Otter says, "That's fine."
Otter says, "But, I'm worried about gathering the management proram suite, so I can explain the cocnepts."
Otter says, "+dispatch is a program to register MUF that can be called from MPI."
Otter says, "+lock lets you set all permissions. +lock #admin lets you set global permissions."
Otter says, "+tune lets you set global configuration (and should include @tune)."
Otter says, "So, if I wanted to write a program that had global setting, such as default length of longest short-description I want shown, I would write the code, have it check its prop on itself just as always, but have the load script register that prop and program with +tune. Is that how we see it?"
Badger says, "That's how +tune currently works."
Otter says, "OK, then my understanding is correct so far. No programmer changes take +tune into account, like they had to do with +lock."
Badger nods.
Otter says, "The MUF coder still does 'prog getprop' or whatever."
Otter says, "But, when he does the lines after the end of the MUF int he load-scrit, he would call '+lock #add' to add his locks, '+tune #add' to add his property settings."
Otter says, "As well as +help, +globals."
Otter says, "To register with those as well."
Badger nods.
Otter says, "OK, I'm just trying to figure out how to write a "This is how to admin an NMC MU" with sections on "Adding code to NMC.""
Badger ahs.
Otter says, "A program may choose to add "hook points" to his code. If he does, he'll have his program call a "hok library" that iterates through the functions (hooks) that were added by others using +hooks. His load-script will register what hook-points as part of the load. Is that how you see it?"
Badger ponders.
Otter says, "I'm not saying "What do we have?" I know we don't have this stuff coded. I just need to know what we're going to do, so I can explain our grand plan. And specify what will be in V 1.23."
Otter says, "OK, let me use jump as an example for hooks."
Badger says, "I could see that, yes."
Otter says, "I see three hooks in jump: permission check after the user has been approved by the lock system, hooks called before he leaves the curent room, hooks called after he arrives in the new room. You could add two more: after he leaves the current room, and before he arrives in the new room."
Badger says, "Wouldn't 'after he leaves' and 'before he arrives' be the same?"
Badger says, "Oh, different data on the stack."
Otter says, "So, I might say something like '+hook #add $~cmd/jump=can_jump=This returns false if the jump shuold be blocked.', '+hook #add $~cmd/jump=before_leave=This is called before the player leaves the source room", and '+hook #add $~cmd/jump=after_arrive=This is called when the jumper is in the new room.""
Otter grins. "Right, each program has its own expectations of what to give and how.
Otter says, "So, those need to be provided. A "checkargs" string, perhaps."
Badger nods. The stringtable uses checkargs.. that's how he found the nice server bug.
Otter says, "Now, who can add hooks? That would be an admin lock, most likely. Unless we hasd a 'hooks lock' that could be set on the MUF itself."
Otter says, "But, the check "No jumping to a room with IC players" would then be added as a hook...and removed from jump."
Badger says, "Or both."
Badger says, "Do I pass admin? No. Do I pass local lock? Yes. Granted."
Otter says, "It would be added as a can_jump hook."
Otter says, "Local would likely be 'default pass'."
Otter says, "Since if we have admin as master, and don't feel like resricting the others, its a shitload easier." (Group chat: staff)
Otter says, "Or two admin locks: hook_any, hook_with_local_check."
Otter says, "If you pass hook_any, you can add a hook. If you don't, but pass hook_with_local_chck, you need to pass the "default deny with controls" lock."
Badger nods.
Otter says, "OK, +lock for permissions, object and global. +tunes for global settings. +set for object settings. +dispatch for callable MUF from MPI, +hook for adding MUF to MUF."
Otter says, "And +help for help, and +globals to be on the list."
Otter says, "Are there any other fundamental admin programs?"
Otter says, "Yes, +list."
Badger says, "+list has a lot of discussing to do >:P"
Otter says, "For all collections, including sub-category world-readable ones."
Otter says, "I did a bunch of docs on +list."
Otter says, "And mailed them to the NMCDev list. Months back."
Otter says, "We need something to replace +skills, too."
Badger nods.
Otter says, "+list perhaps."
Badger says, "+skills is +list, really. And chat is the new libs."
Badger says, "Along with page, say, whisper, etc."
Otter says, "I'm trying to figure out what is the core admin command-suite. If we loaded no programs except these, what would we need to make running the MUCK possible?"
Otter says, "And what libraries are needed to support these?"
Otter says, "See, these are the ones to load first, and all the rest must obey them."
Romaq says, "Init"
Romaq says, "Do we have all our rooms and players in order?"
Badger nods. "Most of them need the lowest level libs. Like lib-string_mgnt.muf and such. ... If considering the newer libs.
Otter says, "I want to be able to draft up "This is where we are going, and why.""
Otter says, "And in that, I need to say, "And this is where we are.""
Badger nods.
Romaq says, "I know our stuff in the 'init' and 'base' directory we were going to thin it out until it bled, and then turn it into a single MUF program that does a 'check yourself' routine on startup."
Otter says, "That is part of the installation. We had a very interesting suggesetion on the list yesterday from Nick. What about 'package' system with checks like Linuxuyses?"
Otter says, "And where do we put it. I can modify loadmuck easily. In fact, I can make loadmuck talk 'better' to our server by adding code to nmcsrvr that helps loadmuck run faster."
Otter says, "Or, we can make the data somehow 'in the MUF' in a program thatis invoked during @mp or something."
Otter says, "Basically, something must decide "Do I have what I need? Do I need to load in a macro to support a feature?""
Romaq says, "Identity, version"
Otter says, "I'd also like to see @mp and @co merged."
Romaq says, "RPM has a database file to maintain identity and versioning."
Romaq says, "You can query that database also."
Otter says, "If we ditch the root room, and have our environment under #0, then our 'identity' would be props on #0."
Otter says, "Meaning that's where we'd store our version DB."
Romaq says, "We started out with 'we want to break room #0 dependency for everything."
Romaq says, "So we are reversing on it?"
Otter says, "We started out with the idea of running test versions on a real server. We decided to break that a long time back."
Otter says, "There was no real interest in multi-MUs on a single server."
Romaq says, "Yeah... way too impractical when it's much cheaper to just pop another test MU* up." (Group chat: staff)
Romaq says, "I think Nameless is as close as it gets with genres.'"
Otter says, "So, with #0 holding Void, Software Environment, we are OK."
Otter says, "We can ditch the 'root room.' And use #0 for identity."
Otter says, "I don't know we need the 'RootWiz' either."
Otter says, "Programmer owns code, Admin is 'forced'. Do we need loader?"
Otter says, "We could load with Programmer."
Romaq says, "It was a security check."
Otter says, "Is it one we need anymore? We over-engineered the thing."
Romaq says, "The original issue may not be valid, but we didn't want loader to own anything."
Romaq says, "Yes we did. :)"
Otter says, "Oh, that's right. Not security, validity. It let us know if things weren't being loaded properly." (Group chat: staff)
Otter says, "Yeah, we still need loader."
Romaq says, "If Loader owns anything, something, somewhere, went wrong."
Otter says, "We don't need default_guest, default_char."
Badger says, "So long as they're redirected to objects."
Otter says, "Those should have their props stored on an object, and be read in the creation process." (Group chat: staff)
Romaq says, "Which we HAVE come to find out... Badger would own something, or @co wasn't implimented."
Otter says, "Badger, their props shouldn't be stored as a model either."
Badger nods.
Badger says, "But there still needs to be something, somewhere, that sais "Put this prop here on connect. Remove this prop on creation. Make sure this prop is valid before creating. Etc.""
Otter says, "They should be a list of properties like +lock does."
Badger nods.
Otter says, "That way, we don't have the props conflict with the object that is holding them." (Group chat: staff)
Otter says, "And +tune can probably set them."
Otter says, "Or something similar."
Otter says, "Ideally, +tune."
Otter says, "Or +hook."
Badger nods.
Otter says, "Then, male and female can be simple characers, who just call 'make guest' on login and that's it. They can have the standard "Do not let me be toaded" be set on them (I added a property for that in the server)."
Otter says, "We can't get away from chown_char, or atlas. But they are both flagged as 'no @toad' and 'no login.'"
Romaq says, "That one's a kicking change. No idea why we didn't scare that up earlier. :)"
************** end **************
Otter says, "Actually, neither of the server-mods was very long. I made both in fairly short order."

Posted on Monday, April 23, 2001, by Romaq (Scripts)