1 2 1. let tinyldap check for and incorporate updates from the journal in 3 the hash table 4 5 2. support modify and delete requests (should be easy) 6 7 9. test whether the acls for add actually work 8 9 10. think about how to incorporate the journal into the database while 10 still allowing new writes. Second journal? Switch to one-process 11 model? 12 13 11. think about compressed database (maybe add first n chars of each 14 string to index to avoid decompressing too much) 15 16[old and obsolete] 17 18 - add auth method (openldap md5: base64, 4 bytes salt, direct hash) 19 - add write support with an external journal 20 We can also implement clustering through this journal. 21 The journal entried need to be timestamped and they need to carry a 22 checksum so we can detect corrupted journals. Journal with FEC? 23 - add ACLs 24 Match as direct string, prefix, suffix, fnmatch or regex 25 The Acl parser should detect duplicate comparisons and combine them 26 so that the matcher only matches once. That way we don't need 27 structure in the ACLs, they can just be massively copy and pasted by 28 the user. 29 ACLs should be able to match by 30 * dn being operated on 31 * dn the user authenticated as 32 * attributes 33 and give the following permissions: 34 * read 35 * write 36 * delete 37 * rename dn 38 * authenticate 39 40Think about a shared calendar in LDAP. Using ISO date format and 41ordered matching it can be done. Design tinyldap so this actually 42scales. How would conflict detection and resolution be done? 43Think about an iCal frontend. 44 45Make tinyldap a good back-end for blogs and message boards. 46 47 48 49 50 51The ACL checks need to include the attributes in the filter of the 52query. Right now, if there is a read ACL prohibiting reading of "sn", 53one could still query all records with (sn=Fnord). 54 55Also, the attribute value list should be fixed up so there are no string 56compares in the attribute check in the acl and normal answers. 57