httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Date Tue, 23 May 2000 23:12:25 GMT
> 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

With the understanding that we don't have to try too hard to maintain
binary compatibility, I'm happy to make ap_xlateattr_t transparent,
which means we can ditch the ap_xlate_create_xlateattr() and
ap_xlate_set_xlateattr_sb() functions.  The app should clear the
ap_xlateattr_t, then set any fields corresponding to attributes they
wish to specify.

What about retrieval (querying attributes)?  I can ditch
ap_xlate_get_sb() and instead provide ap_xlate_get_xlateattr(), which
will fill in an ap_xlateattr_t corresponding to the specified
ap_xlate_t.  Any storage pointed to by the ap_xlateattr_t will be from
the same pool as the ap_xlate_t. 

Does this seem reasonable?  Do you still have a desire to specify
attributes directly in the parameter list to ap_xlate_open()?



Jeff Trawick | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message