> > if you examine tdb.c's design, you will notice that apr_table_do() > > becomes identical to [but more powerful than] tdb_traverse(). > > > > > > apr_array_header_t? again, i haven't thought about it, but > > you could likely get away with the same thing. > > > > The apr_table_t is just an apr_array_header_t with a specific > key/val entry type. > > > in other words, i think that supporting apr_pool_t on top of > > shared memory (via sms) is going to be tricky: in my opinion, > > the apr_pool_xxx() API _and_ the apr_sms_xxx() API can't Deal With > > shared memory at a convenient user-acceptable level. > > > > HOWEVER! supporting the data types that apr_pool_xxx() USES > > is a different matter. > > > > by supporting apr_array_header_t (if possible) and apr_table_t > > the complexity of messing about will be hidden from users of > > these data types, but they will work quite happily as expected, > > even if it's shared memory behind them. > > > > what people think? > > I think you are in for a ride on this one. The API for dealing > with the tables is currently rather poor, since typically it > is casted to an array and then iterated over.
implementation? or usage? implementation, i don't know. usage? i think it's _great_! > The strcasecmp's > of the table code are a whole seperate issue. mmm, setn, set, add and addn _are_ a little weird. plus, you can't typecast from the const char* to a struct* which is what i use it for. ... errr.. should i be using apr_hash_t or something? :) > I would think that > the (nearly analagous) apr_hash_t would better suit what you > are talking about here. ... mmmm soundss like i should be using apr_hash_t _anyway_. will investigate it, get back to you. does apr_hash_t have an apr_hash_do()? oh YUCK. it has one of those horrible non-thread-safeable dbm-like interfaces. the _only_ reason that tdb has a getfirst/getnext is to make it 'look' like gdbm. however, one of the critical things that makes tdb good is that it has tdb_traverse(), which - get this: allows you to guarantee traversal of *all* nodes, even when you are deleting some out from under your nose *simultaneously*. cool, huh? [and it's only 1024 LOC yes i know it's not portable like APR i was v.impressed that someone actually looked at it when i first mentioned it here, btw ] so *grin*. can you guarantee thread-safety on apr_hash_t using apr_hash_first()/next()/this()? can you guarantee complete traversal with multiple simultaneous adders, deleters, readers and writers? and does anyone want a challenge of porting tdb to apr? *grin* > BTW: Why are tables in APR at all? The only thing I see used > is headers in apr-util hooks code, and in the xml, but that of > course can be fixed. Step 1, remove tables from APR, Step 2, > remove tables from Apache. agh! tables are kinda... entrenched into xvl. okay, maybe not: only 10 instances of apr_table_make. 10 of apr_table_do [which is why i was advocating it: i really like it :)] i use it to store the GET/POST args, i use it as a result-table for XML-db-like queries, as a table to add nodes to an XML doc or to add properties to an XML node, for all _sorts_ of horrible things, for which it is ideal.
