httpd-dev mailing list archives

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

While I can truthfully say that I just followed the normal APR tact
regarding opacity, it seems that there are real benefits when you want
to be able to extend certain aspects of the API while maintaining
binary compatibility.  I would be curious as to when you would want to
allow new functionality to be added which would extend ap_xlateattr_t
if the type is not opaque.  Would we have to wait for an APR version
number (major/minor/whatever) change?  I get nervous when I have to be
clairvoyant in order to maintain binary compatibility.

> 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, ...);

Most calls to ap_xlate_open() (there are 7 in CVS) would not care
about the single-byte-only attribute.  I can see ab setting the
single-byte-only attribute and maybe some EBCDIC-specific Apache
initialization doing the same for the headers-to--ascii-and-back
translation setup.

I agree that there would never (or almost never) be sharing of the
attrs between different calls.

I think that the attrs work well in a separate attr structure instead
of directly in the parm list because 

1) We (well, at least I) don't know how many there will be and what
   types they might be.
2) Even if I knew, it would clutter up the parm list for all calls and
   force the caller to know what reasonable default values are for
   each attribute (or at least force APR to provide preprocessor
   macros which evaluate to reasonable default values).

> 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/

Here are some possible attributes (I called them "hints" in the text
below) which I listed a couple of weeks ago:

>I think we need to add some sort of hints argument to
>ap_xlate_open().  The language is one very useful hint to the
>translation mechanism (if it can use it; we must ignore it when the
>mechanism can't handle it).  Other possible hints:
> 
>. what to do if an input character is not in the character set we said
>  it was (e.g., skip bytes in the input until we can translate again)
>. what to do if the input character can't be represented in the target
>  character set (e.g., substitute the appropriate blank)
>. whether or not to signal a permanent error if we get too many
>  translation problems (what is "too many")
>. whether or not the the app can handle non-SBCS translation

The initial implementation just had the single-byte-only attribute.
To me, the biggest argument for using an attribute structure (whether
or not opaque) is that I don't know the complete set of reasonable
attributes for character set translation.

To me, the biggest argument for using an opaque attribute structure is
freeing app A from having to be recompiled if a bug fix for app B
requires that APR's xlate stuff be modified to allow app B to specify
a new attribute.

------------

As a separate issue, what about the style of the function to query an
attribute given a valid translation handle?  Some code that is passed a
translation handle needs to find out whether or not its own
single-byte-only assumption is met.

Thanks,

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message