To: new-httpd@apache.org
Subject: Re: Context types in APR.
References: <Pine.A41.4.05.9905021925530.24202-100000@webdev7.raleigh.ibm.com>
From: Ben Hyde <bhyde@pobox.com>
Date: 03 May 1999 10:12:16 -0400
In-Reply-To: Ryan Bloom's message of "Sun, 2 May 1999 19:40:00 -0400 (EDT)"
Message-ID: <87iuaajl8f.fsf@zap.ne.mediaone.net>
Lines: 76
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


Ryan Bloom <rbb@raleigh.ibm.com> writes:

> Ben Hyde and I have been discussing this off line a little bit, so I am
> bringing this back to new-httpd.  I am going to _try_ to summarize what
> was said, so if I get it wrong Ben, please correct me.
> 
> Ben's position:
> 
> We should forget about context types.  All the stuff we were going to put
> in the context type really belongs in the pool structure.  This basically
> means we are adding a thread pointer, state flags, and possibly other
> fields later to the current Apache pools.  His argument is that the
> context abstraction is unnecessary, and we are better off just adding the
> fields to the current pools.

I try not to let other people's summaries of my positions act as
flame bait.

I'm -1 on contexts until somebody can explain to me what they are for.

I am NOT saying use pools as a junk yard, I'm accusing contexts
of being a junk yard that is holding state that belongs elsewhere

My position: if your going to add an additional parameter to every
single routine in the system then you had better have a DAMN GOOD
description of what it is.

I've been thru every slot in this current proposal and shown they
are unnessary, in most cases a mistake.  I now think this is just
fuzzy thinking.

All routines are methods on objects.  Those objects should contain 
the state required or if not the state should be a parameter.

> Ben also feels ALL apr types should allow users to hang their own data off
> of them.

Yes I do, except those that are always compile time constants.

> My position:
> 
> ...
> 
> I do not see a need to have each apr type allow the user to hang data off
> of them.

Would you argue that threads shouldn't have a place for users to hang
additional state off of?

In anycase it's a fair question.  Read the thread "Subject: tables
with binary data.." in nh.9903.  It's a fine example of how much of
pain it is when people design a data structure that spans some
activity and they assume that the users of that data structure will
have no need to annotate it with data specific to the task they are
working on.  This is particularly true of data structures that have
user defined call backs.

Currently when I write modules if I want to annotate the request, the
connection, the uri, etc. etc. during my handling of the request I
have to build out of band hash tables to do it.  Entirely because the
core forgot to provide a place for me to store my mark ups on the task
at hand.

Since I'd argue that you can't predict which APR types will, in the
fullness of time, have callback hooks invented for them then it's
best to just put the a few bytes in all of them so users can refine
them.

> Work done so far:
> 
> Please disregard the work done so far.  ...

I'm trying...

 - ben