tables with binary data..

[Dirk-Willem van Gulik <di...@webweaving.org>]

For a specific project; I needed to be able to store arbitrary binary data
in the r->notes. The main reason was to pass certain data around between
modules in a certan way. Extending table's 'a' proved fairly
straightforward; and using wrappers with strlen() easy to make backwards
compatible with the old ap_table_* calls. Now it certainly is a bit
wastefull; 4 extra bytes and its struct pointer for each entry. 

Now is this requirment general enough to spend some time on cleaning the 
patch up for a next release ? And secondly.. is the waste (memory and
an extra ptr to follow) worth the functionalyty ? We have done quite
well sofar with strings. 

Or should I have not re-used the existing table typedef, but would it have
been better to have two separate ones table classes; for the string and
for the binary type. (The prime reason for upgrading the existing table
was to reuse the r->notes, but that is a different story).

And finaly would it make sense to keep, besides the extra len data, a
'type' field around as well; in particular so that one can nest a table
inside a table value. Or is that way over the top ?

Dw

Re: tables with binary data..

[tv...@aventail.com]

Dirk-Willem van Gulik <di...@webweaving.org> writes:

> Now is this requirment general enough to spend some time on cleaning the 
> patch up for a next release ? And secondly.. is the waste (memory and
> an extra ptr to follow) worth the functionalyty ? We have done quite
> well sofar with strings. 

I haven't any particular preference on how this should be done. But I do
have this same requirement.

-Tom

Re: tables with binary data..

[bh...@pobox.com]

Cliff Skolnick writes:
> On Fri, 19 Mar 1999 bhyde@pobox.com wrote:
> > 
> > Recently I've thought what I wanted was just a plist with void* key and 
> > value on every server data structure.
> > 
> > That's pretty much where I am today.
> 
> How will you address the issue of when a requests is over the resources need
> to be unallocated.  Are you registering some type of callback to destroy the
> datastructures associated with the void*?

I'm very dependent on, and a big fan of, the pool cleanups.

 - ben

Re: tables with binary data..

[Cliff Skolnick <cl...@steam.com>]

On Fri, 19 Mar 1999 bhyde@pobox.com wrote:
> 
> Recently I've thought what I wanted was just a plist with void* key and 
> value on every server data structure.
> 
> That's pretty much where I am today.

How will you address the issue of when a requests is over the resources need
to be unallocated.  Are you registering some type of callback to destroy the
datastructures associated with the void*?

Would a mechanism to handle a linked list of void* along with an associated
callback to destroy whatever the void* is referring to be useful?

worried about memory leaks...
Cliff

--
Cliff Skolnick
Steam Tunnel Operations
cliff@steam.com
http://www.steam.com/

tables with binary data..

[bh...@pobox.com]

Dirk-Willem van Gulik writes:
> For a specific project; I needed to be able to store arbitrary binary data
> in the r->notes.

Why do I yearn for such things?  I want modules to cooperate on the resulting
content.  The most common case is because I want to associate a thunk/cookie to
characterise both connection to some backend server and the reply being
accumulated.

At first I thought what I wanted was what the Mac. O/S usually
provides, a void* UserData field in every each data structure.
I.e. a poorman's subclassing.  Some days I still think that.  The
rub is who's the "User"?

Then I thought what I wanted was a config style vector on every server
data structure where modules could store module state.  I don't like
having to build a threaded safe hash table internal to the module that
is keyed by the request_rec.

Recently I've thought what I wanted was just a plist with void* key and 
value on every server data structure.

That's pretty much where I am today.

  - ben

Re: tables with binary data..

[Rodent of Unusual Size <Ke...@Golux.Com>]

While adding functions to deal with binary table values has
been on my list for a loong, loong time, I never went so far
as to think of binary key values too.  +1 on that concept.

While treating the current string-based table keys and values
as special cases (namely, turning them into the binary-value
format via wrappers) has a certain elegance, I'm pretty sure
we don't want to do that.  Major time is already spent in
strncmp() because of table lookups; I'd hate to aggravate that
with another indirection fetch.  However, that's just gut
feeling; numbers should speak louder.  If comparison shows the
indirection overhead to be in the noise, I'm all for wrappering
the strings into binary items.  Otherwise, I think we need to
have two distinct sets of functions.

+1 on the concept in any event.
-- 
#ken	P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Group member         <http://www.apache.org/>
"Apache Server for Dummies" <http://WWW.Dummies.Com/