* Add support for YAML and/or other serialisers for method parameter
  passing and return. Blocked waiting on all method IO code requiring and
  always using quotes around string values.

* Make libmooproxy not overload _init which is unportable; instead have it
  lazy-init when the magic chdir is done.

* Add a way for a builder to see all the contents of a container, hidden or
  not.

* The admin should be able to kick people off the moo. Well, you can, but
  you have to find their session and manually eval a command asking the
  session manager to log them out... something easier is called for.

* Should I subclass from the container class for this?
  > 8.  Lockable/unlockable containers
  >       As of the most recent mooix I checked (the latest release before
  > a few hours ago), containers had a locked field but now lock or unlock
  > commands.  Pretty much I'd like container locking/unlocking to act like
  > the door's locking and unlocking, maybe saying that an object has no
  > lock if it's key and manuallock fields aren't set.

* > 4) If you reparent an exit called in to a door (and
  > the same to the other side), when someone goes 
  > through, it says: "you go through the in". But what
  > would be nicer is for it to say "You go through the
  > door".
  
  Yeah, this is a problem. Doors are meant to be used by having "door" as
  their main name, and possibly the direction the door is is as an alias,
  and then the message makes sense. But this leads to a lot of work if you
  dig and then reparent to doors, since you have to reparent, then set the
  alias and the name.
  
  What I'm considering doing is putting in a second form of the dig
  command that makes doors, or adding some bit of syntax to make it make
  doors, or even making it make doors by default into and out of some
  kinds of rooms. Something like that.

* Lambdamoo has a nice generic system for locking objects for or against
  other objects that is accessible to builders. It would be nice to have
  something similar here.

* An object browser for the sysadmin and programmers. This would let
  programmers examine the object hierarchy, browsing from object to object.
  For example, the admin might go to the system/sessionmanager/sessions
  object and kick off a session. This can all be done w/o an object
  browser, but you have to use ugly mooix:/path stuff. Being able to
  essentially be in the same place as these objects, and interact with them
  directly would be much more useful.

* Size limits for containers. Objects should declare their size (and weight),
  and a container should refuse objects of a certain size, or maybe
  calculate the sizes of its contents, and refuse based on that.

  This is a little tricky of course, because some containers might accept
  only big flat objects, while others can take an object of a large volume,
  but not a really long object. But I probably don't want to encode an
  objects entire 3d shape. Hm. A few simple variables, like: 
        - height, width, depth?
        - length of largest dimension?
        - surface area?

  Weight is even more complex, since the weight of a container depends on
  its contents.

* Object collections. Brian Hicks describes one way to implement them:
  Object collections:
          when adding two of the correct type of object together,
                  results in a specialized container (e.g. add the quarter
                  to the dollar results in a wad of cash worth $1.25, or
                  add the ace of spades card to the ten of diamonds card
                  results in a two card deck.)
          Only objects of the specified type can be put in the container
                  (such as type mooix:money or mooix:playing_card)
          taking the penultimate item from the container causes the
                  container to disappear, dropping the last object.
          the container's name will contain either the number of objects
                  contained (a twelve-card deck) or the value of the
                  objects added together (a wad of cash worth $18.50)
          you can specify taking some amount from the container (5
                  cards, $13.00) and receive a smaller collection
                  containing that many objects (or in the case of the
                  cash, a wad of cash containing that much money, erring
                  on the high side if unable to get the exact amount.
          dealing with playing cards might be tricky, since you don't
                  want others to be able to see your hand.  Perhaps the
                  look routine will check if the avatar is holding the
                  cards.

  Money:
        a subclass from collections
        money objects will have a field in which the value of the
                object is stored, suggest having it initially be
                something like "dollars" so that you can have other
                types of money that are good at different places
                (perhaps some vending machines will only accept
                zorkmids and spit out dollars with disdain)
        you can have other types of money (Deutschmarks, for example)
                are worth some amount of dollars that can be
                controlled through inheritance.
        could also use The Awesome Power of MOOIX(tm) to download the
                current exchange rates of different currencies and
                have the values adjust accordingly

* There should be a way to tell the parser to reload the grammar and
  shortcuts files, w/o logging out and in. Actually, it just needs to
  re-exec itself entirely..

* It'd be nice if a command can be prefixed with 'n times', and it just
  repeats it:
  	> dribble the ball ten times
  Probably with a max upper bound; doing it a million times with no way out
  would er, suck!

* One goal I have for the parser is that it should be able to log
  stuff it doesn't understand, to produce stats that moo admins can use to
  improve it. I can think of a few things that could be logged:
        - unknown words. Many will be typos, while others will be
          interesting things that we might want to support. A list ranked
          by a frequency would be most useful.
        - if all the words in a sentence are known, and the sentence fails
          to parse, maybe there is an interesting grammatical form here
          that could be extracted and added to the grammar. (However, the
          current parser does not reliably indicate if it knows all the
          words in a failing parse, so this might be hard to do.)
        - all commands; I may find it useful to see how others use the moo
  I suspect that in many cases users will want the ability to turn off such
  logging. (Or it could ask if the user wants to log that if it fails to
  parse something.)

* Stores

* Make verb search order used by parser configurable. If someone wants a
  moo where an avatar's contents are searched for verbs before the avatar
  itself, that should be easily doable.

* Support zero-g and other gravity environments. Not really hard, just have
  to make the weights be calculated based on object's masses.

* Alex Liebowitz wrote:
  > How about a bare distro without any unnecessary objects in it for building
  > your own system from scratch?

* Hack together a single user mooix varient. This would eliminate mood,
  and have a hacked libmooproxy that just trapped exec, to build up the
  call stacks. It would not enforce any of the security rules. This would
  be a lot faster/simpler for specialized uses (like single player IF games),
  and would be a bit more portable to systems like windows. Optionally,
  ditch callstacks alltogether and the result is just a lot of perl execing
  other perl and C. Of course, the moo obj/ and bindings/ tree should not
  need any changes for these hacked systems, or things would get messy.
  Well, you could modify the perl binding, so you have just one perl
  program loading in and evaling methods (and occaisonally execing some C)..
  perlmoo lives!

Parser stuff:

* Should be able to say "stand on the scale, and then get off",
  and I think the get.cmd is ok, but the parser does not understand the
  form "get off", ie, "verb <weird preposition>"

* It's natural to try to say "the rock is a mooix:foo"
  and expect that to change the parent. Add special case?

* It's natural to want to be able to say "it is hidden and immobile"; the
  parser cannot deal with such things yet tho.

* There should be a field that builders+ can set, that the parser notices
  (like benchmarked), and prints out debugging info about how it parses
  stuff and what verbs it runs.

* Parser gets this wrong: "put all into the box".
  It thinks that the d.o is "all in the box", and there is no i.o.
  Well, the moo should be able to figure out that if I say "verb foo in
  bar", I may mean a foo in the bar, but "foo into bar" does not refer to
  an object in an object. May require a separate preposition class?

* Ok, this should really work; the problem is it doesn't understand
  multiple do_prepositions like this. Maybe do_preps need to be tied to
  the individual d.o.'s, if there are more than one? 
  
  > look in the couch and under the couch
  Rummaging around in the couch, you find the penny.
  You can't do that.
  
  Similarly, I should be able to say "look at the box and at the ball", but it
  chokes on the second "at".. 

* I need to get various combinations of ways of referring to objects
  working again:
  
  > look lint in box's bowl
  It's not clear what you mean by "lint in box's bowl".
  > look bowl in joey's box
  It's not clear what you mean by "bowl in joey's box".
  > look bowl's lint in joey's box
  It's not clear what you mean by "bowl's lint in joey's box".

* This should work. Currently only one level is supported though.

   > look joey's box's ball 
   It's not clear what you mean by "'s ball".

* One should be able to say:

  > look at the bowl in the box
  > look at the lint in that bowl

  And so "that" refers to the last object mentioned with the given name.
