* look into linking with libperl.a on i386, for the non-fpic-speedup.
  Needs benchmarking..

  * Add hack for gettpid(), which is always the same from perl 5.8.1 on.
    (http://xrl.us/xwp)

* zMUD version 6.62 is reported to trigger uninitialized value warnings
  during login.

* in.mooix: I seem to have to hit enter sometimes in gmoo after saving an
  edit before in.mooix sees the MCP command.

* in.mooix: if I run a password method and it gets queued, the callback
  screws up when it runs. It seems that the file handle must be going away
  before then, but is't it lexically scoped? Is something closing it?

* Revisit the issue of how mood runs embedded code. It does the method
  check which involves a secure chdir to the directory containing the
  method, but then it fchdirs back to the object it's called on, and feeds
  a path to the method to the interpreter. Is this vulnerable to races that
  replace a link thus altering the directory that the interpreter finds the
  method in?

  (I seem to remember looking at this once before, dunno.)

* make the parser log when locking an object for a limit fails.

* add debugging calls to all other language bindings..

* capability setting in mood via libcap. Three possible sets, one for
  main mood process, one for methods, and one for mood helper processes:
	
	methods: none! (Already the case, I think?)
	mood helpers: er, also none, I think.
	main mood: CAP_SETGID CAP_SETUID CAP_KILL CAP_SYS_RESOURCE (I think)

	Some of the removed capabilities for root mood will include:
	CAP_NET_BIND_SERVICE CAP_LINUX_IMMUTABLE CAP_SYS_MODULE etc
	Certianly seems worth it!

	Looks like I can get by with setting capabilties at mood start
	time. I could just use the execcap utility in libcap-bin then.

	What about the patches to add cap_user_sock etc?

* I'm in a closed box with a sword in it:

  > take sword
  You can't touch that.

  Simularly, I can take things outside the box while it's closed and I'm in
  it.

  The bug is that the parser's handling of (touchable) goes down the the
  uber-location, and then checks all container between there and the object
  are open. 

  Instead, it should get a list from the user to the uber-location. Then
  start with the object location. Is it on the list? If so, break; if not,
  see if object location is open, if so go down to next location.
  After finding a match, go up the list from location to user, checking
  that all containers are open.

  (visible) and (nearby) may have similar issues.

* antispoofing colorizes wrong objects often. FE:

    The housekeeper arrives and hauls joey off to bed.
                                      ^^^^
  Joey is highlighted, should be housekeeper.

  It should be harder to goof this up than it is. Should probably be less
  avatar-centric, and highlight the object that is sending the message.

* Try to cut down on the number of stackless methods that need to
  grub through the callstack.

  One possibility is to make the owner field a list. Then in eg container
  creation, the contents can be made owned by both the container and the
  container's owner, and no stackless methods would be needed to set it up
  or write to it. 

  An alternative is to make ownership transitive, so the contaner contents
  can be modified by the container's owner. Would this be safe? Efficient?

* "look all" in a dark room enumerates all the objects there; this is a
  stupid hole, but I don't know the best fix for it.

Release checklist for 1.0:
* All items above must be dealt with or postponed to LATER.
* Go through every inch of the help, and try every command in it and make
  sure they still work as advertised and that the example output is correct.
* Update ROADMAP
* Rename TODO-LATER to TODO
* Release :-)
