git.sur5r.net Git - openldap/blob - TODO

   1 Things for 2.5:
   2 [09:27] <hyc> we also need to audit all of these schema defs
   3 [09:27] <hyc> we're supposed to have official, non-experimental OIDs for released schema
   4 [09:28] <hyc> accesslog is still using 666, experimental arc
   5 [09:29] <hyc> I think this means we should polish up the logschema draft, Informational status, and publish it again as final
   6
   7 [13:57] <hyc> there's a nagging problem though, pcache's entry_release function needs to distinguish between its backend actually freeing the entry, or being a no-op
   8 [13:57] <hyc> so it can decide whether to return success or continue
   9 [13:58] <hyc> the patch to translucent sidesteps the question, by avoiding other overlays
  10 [13:58] <hyc> but we need to revisit this in 2.5
  11
  12   ITS#7920 fix for slapacl This needs to be streamlined in 2.5, current tool API is a mess.
  13
  14 ITS#7926 - [18:19] <hyc> this is going to be a WONTFIX for 2.4, I think
  15 [18:20] <hyc> reiniting the listeners array is probably too much of a pain. it will screw with all currently open connections
  16
  17 [10:22] <hyc> and rewriting Bind and Exop result handling
  18 [10:22] <hyc> so that it's no longer a special case for overlays
  19
  20 [23:34] <hyc> ok, so far heap profile shows that memory use during refresh is normal
  21 [23:35] <hyc> not wonderful, but normal. mem usage grows because we're recording the present list while receiving entries in the refresh
  22 [23:36] <hyc> I'm seeing for 1.2GB of data about 235MB of presentlist
  23 [23:36] <hyc> which is pretty awful, considering presentlist is just a list of UUIDs
  24 [23:36] <hyc> being stored in an avl tree
  25 [23:37] <hyc> a btree would have been better here, and we could just use an unsorted segmented array
  26 [23:42] <hyc> for the accumulation phase anyway. we need to be able to lookup records during the delete pphase
  27 [00:05] <hyc> this stuff seriously needs a rewrite
  28 [01:13] <hyc> 2.8M records x 16 bytes per uuid so this should be no more than 48MB of overhead
  29 [01:13] <hyc> and instead it's 3-400MB
  30
  31 <hyc> we need to merge the rest of Ondrej's slapmodify/slapdelete patches
  32 <hyc> get lmdb incremental backup working
  33 <hyc> I need to publish a spec for PREPARE/2-phase commit in LDAP TXNs and integrate that into lmdb and back-mdb
  34
  35 Update slapo-unique to have an option to disable manageDSAit (ITS#8245)
  36
  37 Leftover bits from ITS#8294 -- Drop custom SHA2 code, use default crypto library SHA2 functions instead
  38   May need to document minimum crypto library version requirements
  39   Can also include sha2.c in slapd-sha2.c and make everything static
  40
  41 Matching rules for olc* attrs, see also ITS#8341
  42
  43 New syslog engine
  44
  45 [12:45] <hyc> I meant regcomp and regexec
  46 [12:45] <hyc> mainly - compile a pattern, then fill in substitution parameters later
  47 [12:46] <hyc> yes but the idea is still based on numbered substitution parameters
  48 [12:47] <hyc> it's a pretty obvious approach, and with regex, time-tested.
  49 [12:48] <hyc> I may try to sneak it into OpenLDAP 2.5
  50
  51
  52 Overhaul overlays and backends, see ITS 6166
  53
  54 (In relation to a discussion about slapo-chain)
  55 <hyc> anyway, the nicer ting to fix would be in 2.5, push all of the repl consumer code into its own overlay
  56 <hyc> in that case, updateref would be processed wherever the overlay was configured
  57 <hyc> so no longer tied to the frontend
  58 <hyc> it would also make it more feasible to have multiple different consumer configs in a single DB, each with their own provider URL (and thus their own updateref)
  59 <hyc> I would think we can get rid of the update ref directive entirely, just point all writes to that consumer's provider.
  60
  61 Update dynlist so it works with search filters, so that autogroup can be deleted