1. let tinyldap check for and incorporate updates from the journal in
     the hash table

  2. support modify and delete requests (should be easy)

  9. test whether the acls for add actually work

  10. think about how to incorporate the journal into the database while
      still allowing new writes.  Second journal?  Switch to one-process
      model?

  11. think about compressed database (maybe add first n chars of each
      string to index to avoid decompressing too much)

[old and obsolete]

  - add auth method (openldap md5: base64, 4 bytes salt, direct hash)
  - add write support with an external journal
    We can also implement clustering through this journal.
    The journal entried need to be timestamped and they need to carry a
    checksum so we can detect corrupted journals.  Journal with FEC?
  - add ACLs
    Match as direct string, prefix, suffix, fnmatch or regex
    The Acl parser should detect duplicate comparisons and combine them
    so that the matcher only matches once.  That way we don't need
    structure in the ACLs, they can just be massively copy and pasted by
    the user.
    ACLs should be able to match by
      * dn being operated on
      * dn the user authenticated as
      * attributes
    and give the following permissions:
      * read
      * write
      * delete
      * rename dn
      * authenticate

Think about a shared calendar in LDAP.  Using ISO date format and
ordered matching it can be done.  Design tinyldap so this actually
scales.  How would conflict detection and resolution be done?
Think about an iCal frontend.

Make tinyldap a good back-end for blogs and message boards.





The ACL checks need to include the attributes in the filter of the
query.  Right now, if there is a read ACL prohibiting reading of "sn",
one could still query all records with (sn=Fnord).

Also, the attribute value list should be fixed up so there are no string
compares in the attribute check in the acl and normal answers.