httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Date Tue, 23 May 2000 20:14:45 GMT

Obviously I wasn't clear.  I'm agreeing with you.  I really think I made a
big mistake (taking full blame here) when I made the decision to have APR
use incomplete types for everything.  I think one of the lessons I have
learned in the last week is best seen in the docs I wrote last Friday:

"Having said all of that, sometimes incomplete types just don't make sense."

I think the xlate stuff fits into this category.

Ryan 

On Tue, 23 May 2000, Greg Stein wrote:

> I recognize that threadattr and procattr need to be opaque. But it seems
> that xlateattr is a mechanism for passing known parameters, rather than to
> hide platform-specific issues. I'm open to eduction, however :-)
> 
> Cheers,
> -g
> 
> On Tue, 23 May 2000 rbb@covalent.net wrote:
> > 
> > Threadattr and procattr need to be opaque.  Take a look at the differences
> > between Windows and Unix implementations sometime.  I am about to commit a
> > change to make ap_proc_t's complete and thus non-opaque.  I am sure the
> > xlate stuff is opaque because that was the way APR was written when this
> > stuff we first started.  I have purposefully stayed away from the xlate
> > stuff recently.  I suspect that now that we are trying to "open up" a few
> > of the APR types, the xlate stuff may become a complete type.
> > 
> > Ryan
> > 
> > > I find the whole xlateattr/procattr/threadattr stuff hard to use. There
> > > aren't that many parameters here, and there is not a lot of calling points
> > > in the code. Just pass the dumb params to the function rather than
> > > interposing an opaque(!) structure in the way.
> > > 
> > > pthreads' threadattr makes some sense because it needs to be opaque for
> > > its cross-platform nature. The xlate stuff doesn't seem to need to be
> > > opaque. We support a specific set of parameters, which are well-defined
> > > and portable. Sure, they might be ignored on some platforms, but the
> > > calling code doesn't need to know that.
> > > 
> > > How many places do we use ap_xlate_open? If that happened in a bazillion
> > > places, then maybe the attr stuff would simplify the code. However, I
> > > don't see that we would really be sharing the attrs between the call
> > > points. This means each call would be something like:
> > > 
> > >     ap_xlate_create_xlateattr(&xattr, p);
> > >     ap_xlate_set_xlateattr_sb(xattr, 1);
> > >     ap_xlate_open(&set, xattr, ...);
> > > 
> > > instead of:
> > > 
> > >     ap_xlate_open(&set, 1, ...);
> > > 
> > > 
> > > I'll take the latter any day.
> > > 
> > > How many parameters do we really think will be added? And do we really
> > > have no idea what they would be? IMO, I'll take new constructor functions
> > > and deprecate the old instead of complicating every constructor and use.
> > > 
> > > Cheers,
> > > -g
> > > 
> > > -- 
> > > Greg Stein, http://www.lyra.org/
> > > 
> > 
> > 
> > _______________________________________________________________________________
> > Ryan Bloom                        	rbb@apache.org
> > 406 29th St.
> > San Francisco, CA 94131
> > -------------------------------------------------------------------------------
> > 
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 


_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message