Do before release:

* show me/here repeatedly segfaults; this is new.

These are easy things I recommend to anyone interested in getting
their feet wet:

* Notepads:
	- loading and saving text to object properites and verbs and etc.
	- add a command to subst /// on text
	- add a command to change the location of the insertation point
	- add range support
	- make them somhow be queried for help as a generic object. Hmm..
* 'get down' works in perlmoo - exits should not be pickup-able.
  - I think the way to go is to make a sessile object and make exits
    subclass it. Also makes furniture work. Maybe a flag would be better. Or 
    a function called prior to moves.
* Fix Thing.pm's AUTOLOAD so it detects when you try to run a in-db method
  that has no code, so it doesn't spit out junk and put a VerbCall in the
  caller's properties..
* Modify dig so it checks return codes when adding exits to rooms - if
  permission is denied, it needs to delete the exit it tried to create and
  warn the user.
* Look at perl -ne "print if /\w+->\w+->/" * in many of these, we need to
  make sure $1 returns a true value before going to to look at the whole
  thing. There's only 150 to check! ;-)
* Find places maked FIXME and TODO in the code and fix them.

These are security-related things:

* When in-db code calls the super() method to run overridden methods, there
  is a potential secuity hole. Since the in-db code is running inside a
  safe, we really can't break out and use a different safe for the super()
  code. So what it does is makes a new safe inside the old. (Analagous to
  using chroot, and then running chroot again.) The problem with this is
  that if the child in-db method code wants to, it can fiddle with that
  namespace, and potentially make the parent code do weird things, or even
  replace it with new code that will run as the parent owner.
* Wouldn't it be possible to write an in-db method that changes its owner
  to someone else?

These are harder things:

* Can't override methods of an object, because you really make a method_safe
  command. Anyway, because AUTOLOAD comes last. 2 big problems.
* If something running in a Safe tries to make an Error, that fails because
  Error::new isn't exported into the safe.
* There's a help problem. When upgrading, if help text is modified, the mods
  don't take effect. I guess this applies to other fields too, but it's most
  obvious with help text. The best solution I can think of is to have an
  "old" db, and a "new" db, and look at the user's db... if their db contains
  a value verbatim from the "old" db, then use the one from the "new" db
  instead, otherwise, keep whatever they have. But this is technically hard
  to do, becuase loading 2 db's seperately was never in the design of
  perlmoo.
* The object closure sub is a real mess. Re-write, or something. In
  particular, it will crash and burn if an object has a parent property that's
  not an object. Maybe: Change object properties to each be an object, that
  will have permissions, and will automatically do the inheritcance thing
  and the merging, and all that nastiness.
* Make all methods of Things be in-db methods? Maybe. At least them I could
  implement my own clean inheritance that worked in safe's..
* The question_callback stuff will sometimes ask silly questions. For example,
	create $thing named ball
	create ball named ball
	create ball named ball
  The third command makes it ask you 2 questions, once for the d.o. (needed),
  but also once for the i.o (not needed). It's just a symptom of the d.o.
  and i.o. being looked up too early. Fixing this is _tough_.
* Items from BUGS
* Reserve 100 id numbers somewhere for core object so adding a new core object
  is easier.

Checklist for 1.0:

* Fix all known security problems.
* Get notepads useable.
