You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/05/23 13:46:58 UTC
[PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
This arose out of:
1) discussion a few weekends ago with Dw about information that
ap_xlate_open() could use in the future, such as the language
2) fear that not adding the extra parm to ap_xlate_open() Real Soon
Now would make it harder to add in the future
3) immediate desire to do some single-byte-only checking, before and
after ap_xlate_open()
new structure:
ap_xlateattr_t, to contain attributes related to the creation of
ap_xlate_t
new functions for manipulating ap_xlateattr_t:
ap_xlate_create_xlateattr() - create an empty (default) xlateattr
ap_xlate_set_xlateattr_sb() - manipulate the single-byte-only
attribute (whereby the application can state whether or not it
requires single-byte conversions)
new function for retrieving a certain attribute after creation of
ap_xlate_t:
ap_xlate_get_sb() - retrieve the value of the single-byte-only
attribute
Looking at the names of existing functions in APR...
. for consistency with procattr and threadattr functions, it would
seem that the _xlate_ part of the name should be dropped (but the
pattern ap_xlate_XXX() seems nice to maintain)
. "create" and "set" are not treated similarly with the procattr and
threadattr functions; with create, there is always _ after create,
but with set there is never _ after set
Index: src/lib/apr/include/apr_xlate.h
===================================================================
RCS file: /home/cvs/apache-2.0/src/lib/apr/include/apr_xlate.h,v
retrieving revision 1.2
diff -u -r1.2 apr_xlate.h
--- src/lib/apr/include/apr_xlate.h 2000/05/10 19:45:31 1.2
+++ src/lib/apr/include/apr_xlate.h 2000/05/23 02:41:19
@@ -74,13 +74,20 @@
#if ! APR_HAS_XLATE
typedef void ap_xlate_t;
+typedef void ap_xlateattr_t;
/* For platforms where we don't bother with translating between charsets,
* these are macros which always return failure.
*/
-#define ap_xlate_open(convset, topage, frompage, pool) APR_ENOTIMPL
+#define ap_xlate_open(convset, xattr, topage, frompage, pool) APR_ENOTIMPL
+#define ap_xlate_create_xlateattr(newxattr, pool) APR_ENOTIMPL
+
+#define ap_xlate_set_xlateattr_sb(xattr, onoff) APR_ENOTIMPL
+
+#define ap_xlate_get_sb(convset, onoff) APR_ENOTIMPL
+
#define ap_xlate_conv_buffer(convset, inbuf, inbytes_left, outbuf, \
outbytes_left) APR_ENOTIMPL
@@ -97,17 +104,20 @@
#else /* ! APR_HAS_XLATE */
typedef struct ap_xlate_t ap_xlate_t;
+typedef struct ap_xlateattr_t ap_xlateattr_t;
/*
-=head1 ap_status_t ap_xlate_open(ap_xlate_t **convset, const char *topage, const char *frompage, ap_pool_t *pool)
+=head1 ap_status_t ap_xlate_open(ap_xlate_t **convset, ap_xlateattr_t *xattr, const char *topage, const char *frompage, ap_pool_t *pool)
B<Set up for converting text from one charset to another.>
arg 1) The handle to be filled in by this function
- arg 2) The name of the target charset
- arg 3) The name of the source charset
- arg 4) The pool to use
+ arg 2) The xlateattr to use to determine characteristics of the conversion,
+ or NULL if defaults are to be used
+ arg 3) The name of the target charset
+ arg 4) The name of the source charset
+ arg 5) The pool to use
B<NOTE>: Specify APR_DEFAULT_CHARSET for one of the charset
names to indicate the charset of the source code at
@@ -120,10 +130,58 @@
=cut
*/
-ap_status_t ap_xlate_open(ap_xlate_t **convset, const char *topage,
- const char *frompage, ap_pool_t *pool);
+ap_status_t ap_xlate_open(ap_xlate_t **convset, ap_xlateattr_t *xattr,
+ const char *topage, const char *frompage,
+ ap_pool_t *pool);
#define APR_DEFAULT_CHARSET NULL
+
+/*
+
+=head1 ap_status_t ap_xlate_create_xlateattr(ap_xlateattr_t **newxattr, ap_pool_t *pool)
+
+B<Create and initialize a new xlateattr variable>
+
+ arg 1) The newly created xlateattr
+ arg 2) The pool to use
+
+=cut
+ */
+ap_status_t ap_xlate_create_xlateattr(ap_xlateattr_t **newxattr, ap_pool_t *pool);
+
+/*
+
+=head1 ap_status_t ap_xlate_set_xlateattr_sb(ap_xlateattr_t *xattr, int onoff)
+
+B<Set single-byte-only flag.>
+
+ arg 1) The xlateattr to affect
+ arg 2) Single-byte-only flag
+
+B<NOTE>: When the single-byte-only flag is set, ap_xlate_open() will
+ fail if the specified conversion is not single-byte.
+ Applications which can only handle single-byte conversions
+ (i.e., bytes on output always the same as bytes on input)
+ should set this attribute.
+
+=cut
+ */
+ap_status_t ap_xlate_set_xlateattr_sb(ap_xlateattr_t *xattr, int onoff);
+
+/*
+
+=head1 ap_status_t ap_xlate_get_sb(ap_xlate_t *convset, int *onoff)
+
+B<Find out whether or not the specified conversion is single-byte-only.>
+
+ arg 1) The handle allocated by ap_xlate_open, specifying the parameters
+ of conversion
+ arg 2) Output: whether or not the conversion is single-byte-only
+
+=cut
+ */
+
+ap_status_t ap_xlate_get_sb(ap_xlate_t *convset, int *onoff);
/*
Index: src/lib/apr/i18n/unix/xlate.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/lib/apr/i18n/unix/xlate.c,v
retrieving revision 1.4
diff -u -r1.4 xlate.c
--- src/lib/apr/i18n/unix/xlate.c 2000/05/23 01:58:46 1.4
+++ src/lib/apr/i18n/unix/xlate.c 2000/05/23 02:41:19
@@ -81,6 +81,10 @@
#endif
};
+struct ap_xlateattr_t {
+ int sb_only; /* caller can only handle single-byte conversion */
+};
+
/* get_default_codepage()
*
* simple heuristic to determine codepage of source code so that
@@ -168,8 +172,9 @@
}
#endif /* HAVE_ICONV */
-ap_status_t ap_xlate_open(ap_xlate_t **convset, const char *topage,
- const char *frompage, ap_pool_t *pool)
+ap_status_t ap_xlate_open(ap_xlate_t **convset, ap_xlateattr_t *xattr,
+ const char *topage, const char *frompage,
+ ap_pool_t *pool)
{
ap_status_t status;
ap_xlate_t *new;
@@ -217,6 +222,13 @@
#endif /* HAVE_ICONV */
if (found) {
+ /* Make sure any desired conversion characteristics are met.
+ */
+ if (xattr) {
+ if (xattr->sb_only && !new->sbcs_table) {
+ return EINVAL;
+ }
+ }
*convset = new;
ap_register_cleanup(pool, (void *)new, ap_xlate_cleanup,
ap_null_cleanup);
@@ -228,6 +240,28 @@
}
return status;
+}
+
+ap_status_t ap_xlate_create_xlateattr(ap_xlateattr_t **new, ap_pool_t *pool)
+{
+ *new = ap_pcalloc(pool, sizeof(ap_xlateattr_t));
+ if (!*new) {
+ return APR_ENOMEM;
+ }
+
+ return APR_SUCCESS;
+}
+
+ap_status_t ap_xlate_set_xlateattr_sb(ap_xlateattr_t *xattr, int onoff)
+{
+ xattr->sb_only = onoff;
+ return APR_SUCCESS;
+}
+
+ap_status_t ap_xlate_get_sb(ap_xlate_t *convset, int *onoff)
+{
+ *onoff = convset->sbcs_table != NULL;
+ return APR_SUCCESS;
}
ap_status_t ap_xlate_conv_buffer(ap_xlate_t *convset, const char *inbuf,
Index: src/lib/apr/test/testmd5.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/lib/apr/test/testmd5.c,v
retrieving revision 1.1
diff -u -r1.1 testmd5.c
--- src/lib/apr/test/testmd5.c 2000/05/06 13:41:58 1.1
+++ src/lib/apr/test/testmd5.c 2000/05/23 02:41:21
@@ -156,7 +156,7 @@
if (src) {
#if APR_HAS_XLATE
- rv = ap_xlate_open(&xlate, dst, src, pool);
+ rv = ap_xlate_open(&xlate, NULL, dst, src, pool);
if (rv) {
char buf[80];
Index: src/main/util_ebcdic.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/main/util_ebcdic.c,v
retrieving revision 1.6
diff -u -r1.6 util_ebcdic.c
--- src/main/util_ebcdic.c 2000/05/18 19:54:44 1.6
+++ src/main/util_ebcdic.c 2000/05/23 02:41:23
@@ -110,14 +110,16 @@
ap_status_t rv;
char buf[80];
- rv = ap_xlate_open(&ap_hdrs_to_ascii, "ISO8859-1", APR_DEFAULT_CHARSET, pool);
+ rv = ap_xlate_open(&ap_hdrs_to_ascii, NULL,
+ "ISO8859-1", APR_DEFAULT_CHARSET, pool);
if (rv) {
ap_log_error(APLOG_MARK, APLOG_ERR, rv, NULL,
"ap_xlate_open() failed");
return rv;
}
- rv = ap_xlate_open(&ap_hdrs_from_ascii, APR_DEFAULT_CHARSET, "ISO8859-1", pool);
+ rv = ap_xlate_open(&ap_hdrs_from_ascii, NULL,
+ APR_DEFAULT_CHARSET, "ISO8859-1", pool);
if (rv) {
ap_log_error(APLOG_MARK, APLOG_ERR, rv, NULL,
"ap_xlate_open() failed");
Index: src/support/ab.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/support/ab.c,v
retrieving revision 1.16
diff -u -r1.16 ab.c
--- src/support/ab.c 2000/05/19 22:39:40 1.16
+++ src/support/ab.c 2000/05/23 02:41:26
@@ -967,12 +967,14 @@
ap_create_pool(&cntxt, NULL);
#ifdef NOT_ASCII
- status = ap_xlate_open(&to_ascii, "ISO8859-1", APR_DEFAULT_CHARSET, cntxt);
+ status = ap_xlate_open(&to_ascii, NULL,
+ "ISO8859-1", APR_DEFAULT_CHARSET, cntxt);
if (status) {
fprintf(stderr, "ap_xlate_open(to ASCII)->%d\n", status);
exit(1);
}
- status = ap_xlate_open(&from_ascii, APR_DEFAULT_CHARSET, "ISO8859-1", cntxt);
+ status = ap_xlate_open(&from_ascii, NULL,
+ APR_DEFAULT_CHARSET, "ISO8859-1", cntxt);
if (status) {
fprintf(stderr, "ap_xlate_open(from ASCII)->%d\n", status);
exit(1);
Index: src/support/htdigest.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/support/htdigest.c,v
retrieving revision 1.9
diff -u -r1.9 htdigest.c
--- src/support/htdigest.c 2000/05/06 13:41:59 1.9
+++ src/support/htdigest.c 2000/05/23 02:41:26
@@ -235,7 +235,8 @@
ap_create_pool(&cntxt, NULL);
#ifdef CHARSET_EBCDIC
- rv = ap_xlate_open(&to_ascii, "ISO8859-1", APR_DEFAULT_CHARSET, cntxt);
+ rv = ap_xlate_open(&to_ascii, NULL,
+ "ISO8859-1", APR_DEFAULT_CHARSET, cntxt);
if (rv) {
fprintf(stderr, "ap_xlate_open(): %s (%d)\n",
ap_strerror(rv, line, sizeof(line)), rv);
Index: src/support/htpasswd.c
===================================================================
RCS file: /home/cvs/apache-2.0/src/support/htpasswd.c,v
retrieving revision 1.14
diff -u -r1.14 htpasswd.c
--- src/support/htpasswd.c 2000/05/16 19:48:08 1.14
+++ src/support/htpasswd.c 2000/05/23 02:41:27
@@ -386,7 +386,8 @@
atexit(ap_terminate);
ap_create_pool(&pool, NULL);
- rv = ap_xlate_open(&to_ascii, "ISO8859-1", APR_DEFAULT_CHARSET, pool);
+ rv = ap_xlate_open(&to_ascii, NULL,
+ "ISO8859-1", APR_DEFAULT_CHARSET, pool);
if (rv) {
fprintf(stderr, "ap_xlate_open(to ASCII)->%d\n", rv);
exit(1);
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Posted by rb...@covalent.net.
My original intent (I emphasize MY, because this is my opinion, not the
groups), was that APR should be treated like the C Run-time library. We
always did everything we could to enforce binary backwards
compatability. This seems difficult now. So, my opinion has changed. I
now believe that APR should ALWAYS been binary backwards compatible within
major releases, between major releases, we can break whatever we want.
Because this is open source, I would expect that we can release a new
major release whenever we break binary backwards compatability for APR
though, so this should be easy to accomplish.
Ryan
On Tue, 23 May 2000, Jeff Trawick wrote:
> A few minutes ago, I said
>
> > 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.
>
> This seems pretty silly in retrospect... we don't have to do that, do
> we?
>
> At what point can we force apps to:
>
> 1) recompile if APR is dynamically loaded and they get a new copy (for
> Apache's benefit) which has an updated interface
> 2) modify source code in order to still compile with a new APR
>
> --
> Jeff Trawick | trawick@ibm.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Posted by Jeff Trawick <tr...@bellsouth.net>.
A few minutes ago, I said
> 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.
This seems pretty silly in retrospect... we don't have to do that, do
we?
At what point can we force apps to:
1) recompile if APR is dynamically loaded and they get a new copy (for
Apache's benefit) which has an updated interface
2) modify source code in order to still compile with a new APR
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Posted by Jeff Trawick <tr...@bellsouth.net>.
> 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...
Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Posted by Greg Stein <gs...@lyra.org>.
On Tue, 23 May 2000, Jeff Trawick wrote:
>...
> 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()?
Why deal with a structure just to pass some parameters? Yes: I favor just
adding parameters to ap_xlate_open().
Within minor releases, we can add extra parameters to new functions such
as ap_xlate_open2(). At the major release, we drop the openN() functions
and go back to a single ap_xlate_open().
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: binary compatibility for APR
Posted by Greg Stein <gs...@lyra.org>.
On Thu, 25 May 2000, Tony Finch wrote:
> Greg Stein <gs...@lyra.org> wrote:
> >On Tue, 23 May 2000, Jeff Trawick wrote:
> >> On the other hand...
> >>
> >> If the app has APR statically linked, no problem...
> >
> >I was considering at link time, when the app links against "libapr.a",
> >that APR_VERSION helps that case.
>
> IMO if the person compiling the application can't get the right
> version of APR to link then they deserve to lose. And I'd expect
> either the compile or the link to fail well before it gets to run
> time.
>
> I don't see the point of this change.
Since we have a function that needs to be called before anything else, it
provides an easy, quick point to provide an idiot check.
We build version checking into Apache itself, system libraries such as
WinSock provide APIs for version checking, etc. This is a low-cost check
which can quickly provide correct/clear feedback about a problem.
"deserve to lose" ... sure, we can also write Apache in assembler and
state that anybody who doesn't understand it "deserves to lose." :-) I
don't see a reason to punish idiots :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: binary compatibility for APR
Posted by Tony Finch <do...@dotat.at>.
Greg Stein <gs...@lyra.org> wrote:
>On Tue, 23 May 2000, Jeff Trawick wrote:
>> On the other hand...
>>
>> If the app has APR statically linked, no problem...
>
>I was considering at link time, when the app links against "libapr.a",
>that APR_VERSION helps that case.
IMO if the person compiling the application can't get the right
version of APR to link then they deserve to lose. And I'd expect
either the compile or the link to fail well before it gets to run
time.
I don't see the point of this change.
Tony.
--
f.a.n.finch fanf@demon.net dot@dotat.at
278 shower from the clocktower
Re: binary compatibility for APR
Posted by rb...@covalent.net.
> > > Yes... if the major version is encoded in the name, then a number of
> > > problems are solved. However, I think we can increase the safety by using
> > > APR_VERSION. Since we have an "init/terminate" semantic, this should be
> > > very easy to implement.
> > >
> > > Cheers,
> > > -g
> >
> > go for it (as far as I'm concerned :) )
>
>
> Ryan? Any problems with this?
Nope. Go ahead.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: binary compatibility for APR
Posted by Greg Stein <gs...@lyra.org>.
On Wed, 24 May 2000, Jeff Trawick wrote:
>...
> > Yes... if the major version is encoded in the name, then a number of
> > problems are solved. However, I think we can increase the safety by using
> > APR_VERSION. Since we have an "init/terminate" semantic, this should be
> > very easy to implement.
> >
> > Cheers,
> > -g
>
> go for it (as far as I'm concerned :) )
Ryan? Any problems with this?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: binary compatibility for APR
Posted by Jeff Trawick <tr...@bellsouth.net>.
> Date: Wed, 24 May 2000 14:23:39 -0700 (PDT)
> From: Greg Stein <gs...@lyra.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> X-UIDL: 9aface625f8950cd94abc6417c7f321c
>
> On Tue, 23 May 2000, Jeff Trawick wrote:
> > On the other hand...
> >
> > If the app has APR statically linked, no problem...
>
> I was considering at link time, when the app links against "libapr.a",
> that APR_VERSION helps that case.
>
> > If the app does not have APR statically linked, it could be loading
> > something with the version number in it (libapr.so, libapr.so.1,
> > libapr.so.2, etc.).
>
> Yes... if the major version is encoded in the name, then a number of
> problems are solved. However, I think we can increase the safety by using
> APR_VERSION. Since we have an "init/terminate" semantic, this should be
> very easy to implement.
>
> Cheers,
> -g
go for it (as far as I'm concerned :) )
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: binary compatibility for APR
Posted by Greg Stein <gs...@lyra.org>.
On Tue, 23 May 2000, Jeff Trawick wrote:
> On the other hand...
>
> If the app has APR statically linked, no problem...
I was considering at link time, when the app links against "libapr.a",
that APR_VERSION helps that case.
> If the app does not have APR statically linked, it could be loading
> something with the version number in it (libapr.so, libapr.so.1,
> libapr.so.2, etc.).
Yes... if the major version is encoded in the name, then a number of
problems are solved. However, I think we can increase the safety by using
APR_VERSION. Since we have an "init/terminate" semantic, this should be
very easy to implement.
Cheers,
-g
>
> > Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
> > Precedence: bulk
> > X-No-Archive: yes
> > Reply-To: new-httpd@apache.org
> > list-help: <ma...@apache.org>
> > list-unsubscribe: <ma...@apache.org>
> > list-post: <ma...@apache.org>
> > Date: Tue, 23 May 2000 17:18:25 -0700 (PDT)
> > From: Greg Stein <gs...@lyra.org>
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> > X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
> > X-UIDL: 4dc0863385099ee228a30e320798e222
> >
> > On Tue, 23 May 2000, Jeff Trawick wrote:
> > >...
> > > With the understanding that we don't have to try too hard to maintain
> > > binary compatibility,
> >
> > This made me think of something...
> >
> > It would seem reasonable to change the call to ap_initialize() to take a
> > parameter. The param would contain the version number that the app was
> > compiled with. APR can then check for major-version compatibility.
> >
> > For example:
> >
> >
> > #define APR_VERSION ((APR_MAJOR << 16) | APR_MINOR)
> >
> > app.c:
> > ...
> > if (ap_initialize(APR_VERSION) != APR_SUCCESS) exit(1);
> > ...
> >
> >
> > apr/.../start.c:
> >
> > ap_status_t ap_initialize(int compiled_for_vsn)
> > {
> > if ((compiled_for_vsn >> 16) != APR_MAJOR)
> > return APR_EBADMAJOR;
> > ...
> >
> >
> >
> > As the app is recompiled, it picks up the new APR interfaces and the new
> > APR_VERSION to pass to ap_initialize(). If the app statically/dynamically
> > links against a pre-built APR, then the compiled-in APR_VERSION can be
> > used by ap_initialize() to determine acceptability.
> >
> > Thoughts?
> >
> > Cheers,
> > -g
> >
> > --
> > Greg Stein, http://www.lyra.org/
> >
> >
>
>
> --
> Jeff Trawick | trawick@ibm.net | PGP public key at web site:
> http://www.geocities.com/SiliconValley/Park/9289/
> Born in Roswell... married an alien...
>
--
Greg Stein, http://www.lyra.org/
Re: binary compatibility for APR
Posted by Jeff Trawick <tr...@bellsouth.net>.
On the other hand...
If the app has APR statically linked, no problem...
If the app does not have APR statically linked, it could be loading
something with the version number in it (libapr.so, libapr.so.1,
libapr.so.2, etc.).
> Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
> Precedence: bulk
> X-No-Archive: yes
> Reply-To: new-httpd@apache.org
> list-help: <ma...@apache.org>
> list-unsubscribe: <ma...@apache.org>
> list-post: <ma...@apache.org>
> Date: Tue, 23 May 2000 17:18:25 -0700 (PDT)
> From: Greg Stein <gs...@lyra.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
> X-UIDL: 4dc0863385099ee228a30e320798e222
>
> On Tue, 23 May 2000, Jeff Trawick wrote:
> >...
> > With the understanding that we don't have to try too hard to maintain
> > binary compatibility,
>
> This made me think of something...
>
> It would seem reasonable to change the call to ap_initialize() to take a
> parameter. The param would contain the version number that the app was
> compiled with. APR can then check for major-version compatibility.
>
> For example:
>
>
> #define APR_VERSION ((APR_MAJOR << 16) | APR_MINOR)
>
> app.c:
> ...
> if (ap_initialize(APR_VERSION) != APR_SUCCESS) exit(1);
> ...
>
>
> apr/.../start.c:
>
> ap_status_t ap_initialize(int compiled_for_vsn)
> {
> if ((compiled_for_vsn >> 16) != APR_MAJOR)
> return APR_EBADMAJOR;
> ...
>
>
>
> As the app is recompiled, it picks up the new APR interfaces and the new
> APR_VERSION to pass to ap_initialize(). If the app statically/dynamically
> links against a pre-built APR, then the compiled-in APR_VERSION can be
> used by ap_initialize() to determine acceptability.
>
> Thoughts?
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
binary compatibility for APR
Posted by Greg Stein <gs...@lyra.org>.
On Tue, 23 May 2000, Jeff Trawick wrote:
>...
> With the understanding that we don't have to try too hard to maintain
> binary compatibility,
This made me think of something...
It would seem reasonable to change the call to ap_initialize() to take a
parameter. The param would contain the version number that the app was
compiled with. APR can then check for major-version compatibility.
For example:
#define APR_VERSION ((APR_MAJOR << 16) | APR_MINOR)
app.c:
...
if (ap_initialize(APR_VERSION) != APR_SUCCESS) exit(1);
...
apr/.../start.c:
ap_status_t ap_initialize(int compiled_for_vsn)
{
if ((compiled_for_vsn >> 16) != APR_MAJOR)
return APR_EBADMAJOR;
...
As the app is recompiled, it picks up the new APR interfaces and the new
APR_VERSION to pass to ap_initialize(). If the app statically/dynamically
links against a pre-built APR, then the compiled-in APR_VERSION can be
used by ap_initialize() to determine acceptability.
Thoughts?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Posted by Jeff Trawick <tr...@bellsouth.net>.
> 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()?
Thanks,
Jeff
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Posted by rb...@covalent.net.
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
-------------------------------------------------------------------------------
Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Posted by Greg Stein <gs...@lyra.org>.
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/
Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Posted by rb...@covalent.net.
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
-------------------------------------------------------------------------------
Re: [PATCH] ap_xlateattr_t for passing options to ap_xlate_open()
Posted by Greg Stein <gs...@lyra.org>.
On Tue, 23 May 2000, Jeff Trawick wrote:
>...
> new structure:
>
> ap_xlateattr_t, to contain attributes related to the creation of
> ap_xlate_t
>
> new functions for manipulating ap_xlateattr_t:
>
> ap_xlate_create_xlateattr() - create an empty (default) xlateattr
> ap_xlate_set_xlateattr_sb() - manipulate the single-byte-only
> attribute (whereby the application can state whether or not it
> requires single-byte conversions)
>
> new function for retrieving a certain attribute after creation of
> ap_xlate_t:
>
> ap_xlate_get_sb() - retrieve the value of the single-byte-only
> attribute
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/