Fw: SHA1 and Base64
From: [EMAIL PROTECTED] To: Greg Stein [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] We can stratify and create as many layers in Apache as we want to put up with. But when we're talking about a *portability* library, then it should focus on just that. All of the code we are talking about is portable code, it may not have portability issues itself, but programs that use this code do have portability issues, and have an MD5 hash or SHA1 and Base64 encoding do allow those programs to be more portable. As a poor, downtrodden Win32 guy... I entirely agree. There is lots of stuff implemented as unix/v or freebsd libraries that just aren't portable without cygwin. We aren't trying to be cygwin, but trying to offer some cross platform fn's with native optmizations. There is nothing wrong with translations, hashing, tables or encodings implemented in APR, there just has to be someone who might need the features. I'm questioning if/how much of/ iconv we should be distributing. But any which way, we should be providing these simple data types to make c coding easier and more portable across platforms. We rejected a mission statment that said apr was nothing but portability... the fns we are discussing are all very reasonable tools to include in APR (including base64/sha1). Put them into a 'lib' or 'util' section, or whatever, but arguing is pointless.
Re: Fw: SHA1 and Base64
On Tue, Nov 28, 2000 at 05:03:49PM -0800, William A. Rowe, Jr. wrote: From: [EMAIL PROTECTED] To: Greg Stein [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] We can stratify and create as many layers in Apache as we want to put up with. But when we're talking about a *portability* library, then it should focus on just that. All of the code we are talking about is portable code, it may not have portability issues itself, but programs that use this code do have portability issues, and have an MD5 hash or SHA1 and Base64 encoding do allow those programs to be more portable. As a poor, downtrodden Win32 guy... I entirely agree. There is lots of stuff implemented as unix/v or freebsd libraries that just aren't portable without cygwin. We aren't trying to be cygwin, but trying to offer some cross platform fn's with native optmizations. There is nothing wrong with translations, hashing, tables or encodings implemented in APR, there just has to be someone who might need the features. There is a large distinction between we help you write your program and we help you to make a portable program. I'm questioning if/how much of/ iconv we should be distributing. But any At 8M of *source*, I don't believe it should be built into APR, but should be a separately downloadable package. which way, we should be providing these simple data types to make c coding easier and more portable across platforms. We rejected a mission statment that said apr was nothing but portability... The mission talkes about a system portability layer. So I don't know what you mean by rejected. the fns we are discussing are all very reasonable tools to include in APR (including base64/sha1). Put them into a 'lib' or 'util' section, or whatever, but arguing is pointless. Nobody is arguing. Discussion, yes, but argue has a connotation which I don't think fits. But regardless, it *does* have a point. Do you want somebody to turn APR into something that you think is totally in the wrong direction? That doesn't move towards it true goal [as you see it?]. I wouldn't think so, and I don't think anybody else does either. We are discussing what to do because we want to see the Right Thing done, however we happen to define/see as the Right Thing. But... this may be moot if we move forward on the APRUTIL idea. The only question at that point will be what goes in there? Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: new APR package
On Wed, Nov 29, 2000 at 02:59:12AM +0100, Branko Cibej wrote: Greg Stein wrote: I think that's all that I've got. Thoughts? Comments? Maybe tweak APR scrpits so that they automagically find, configure and build APRUTIL if somebody happens to unpack it (or checkout) in the APR top-level directory? Then those users of APR that need APRUTIL too will only have to deal with a single package (but would still link two libraries, of course). The dependency goes the other way: APRUTIL depends upon APR. APR will know nothing about APRUTIL. Now... your statement could be applied to APRUTIL: if APRUTIL finds APR unpacked inside it, then it would do the right magic. [ much like SVN does sub-config on APR and Neon which are unpacked inside of its directory (altho the SVN case requires the subpackages) ] It also seems feasible to create a super package of APR and APRUTIL. I would even presume that if somebody builds an APR RPM, they would include both libraries in it. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: new APR package
On Tue, 28 Nov 2000, Greg Stein wrote: Okay... we seem to have some general agreement to make a non-core APR package that contains the purely portable items. With that in mind, here are my rough ideas/notes on this: *) create a new CVS module: /home/cvs/aprutil [ other suggested names? aprkitchensink? :-) ] [ I'll refer to it as APRUTIL for this message's purposes... ] Would /home/cvs/apr-util be OK? That would save me some structural foo with mailing lists all. Is a separate dev cvs list desired? Brian
Re: SHA1 and Base64
Well, it has been suggested that we create a new APR utility library. The discussion on that *just* opened today. It looks like we have several +1 on the concept, and I posted an outline of my thoughts on it. Presuming nobody pops up with a Dood. Big, Bad Idea., then we'll probably start on that path. How soon will depend a lot on what kind of discussion occurs when people wake up tomorrow :-) In any case... what I'm saying is that your idea may have merit, but it is probably easier to start with just one more library and go from there. Cheers, -g On Tue, Nov 28, 2000 at 06:45:57PM -0800, Cliff Woolley wrote: --- William A. Rowe, Jr. [EMAIL PROTECTED] wrote: But any which way, we should be providing these simple data types to make c coding easier and more portable across platforms. I was thinking the same thing. At the risk of adding too much complexity, let me make a suggestion. Part of the problem in all of this is the confusion about what goes where because of unclear definitions created by an attempt to stick too broad a set of functionality into too few packages. What we have now, obviously, is: Apache | APR Duh. The problem, though, is what to do with the stuff that we want to separate from Apache such that it can be used by other packages if it isn't a perfect fit for APR (or over-extends the definition of APR, depending on how you look at it). So aputil was suggested on the Apache list to sit between Apache and APR and to be sort of a kitchen-sink of all the non-Apache specific but non-APR-ideal functionality. But what goes in aputil versus Apache versus APR is unclear, because there's no consistency there. (Among the suggestions for those of you who weren't listening on new-httpd: a generic dbm interface; buckets, rings, SHA1, base64, URI, and XML from Apache; tables, arrays, and hashes from APR.) Apache | APUTIL (dbm, buckets, rings, SHA1, base64, URI, XML, and | maybe tables, arrays, and hashes) | APR (fundamental data types (eg apr_uint32_t), pools and whichever of the above are needed by APR) The whichever of the above are needed by APR seems artificial to me... that might change over time. Say we shift arrays up into aputil for now, but then really really need them later in APR. They move back down. UGH. Ryan said that his vision of aputil had been that it would be a sort of User-Agent utility library for things such as URI parsing. base64 and SHA1 might also fit in with that. As for the DBM thing, if you ask me that's a portability issue (not OS portability, but DBM-implementation portability), so it should be at least as low as the APR layer. I say as low as because I think there should be four layers: Apache | APUTIL (URI, XML, SHA1, base64, (maybe MD5?)) | APR (advanced fundamental data types (eg apr_file_t), advanced buckets) | APRDATA (basic fundamental data types, pools, tables, arrays, hashes, basic buckets, rings) Obviously this still leaves a little room for discussion, but at least to me it seems to make things a little more straight-forward. Pros: (1) APRDATA is standalone, so even really simple programs can benefit from the nice programming environment it provides (eg pools, etc). Also, all of these data structures get to live in the same place. (2) APR becomes much more focused: Portability as opposed to Portable Code... this is largely I/O, of course, but also DSO's, the translation stuff and all of the other APR goodies. (3) APUTIL is a somewhat more sensible set of functionality. Cons: (1) Obviously some functionality of the data structures (eg file, mmap, socket, and pipe buckets) is dependent upon APR. Therefore only the basic buckets go in APRDATA... bucket types that depend upon APR functionality are APR extensions to APRDATA. That's the whole point of extensible buckets, but do we want to have some buckets defined in one place and others in another place? Call this a potential con. (2) Yet ANOTHER layer... this might be getting too complicated. (3) Other problems I haven't thought of yet (I'm sure you all will. ;-) So APRDATA and APUTIL can be separate libraries (separate configuration and all for easy extrication), but APRDATA can be packaged with APR and APUTIL with Apache. What do people think? --Cliff __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ -- Greg Stein, http://www.lyra.org/
Re: new APR package
On Tue, Nov 28, 2000 at 06:45:03PM -0800, Brian Behlendorf wrote: On Tue, 28 Nov 2000, Greg Stein wrote: Okay... we seem to have some general agreement to make a non-core APR package that contains the purely portable items. With that in mind, here are my rough ideas/notes on this: *) create a new CVS module: /home/cvs/aprutil [ other suggested names? aprkitchensink? :-) ] [ I'll refer to it as APRUTIL for this message's purposes... ] Would /home/cvs/apr-util be OK? That would save me some structural foo with mailing lists all. This will be fine, but let's hold off for a day or two. There hasn't been any real discussion (based on my email proposal). But one point to make: the CVS module will be apr-FOO (where FOO is util, or some other name we decide upon). Is a separate dev cvs list desired? Nope. IMO, the distinction is based on semantics and organizational needs. The same set of people will be developing/maintaining it. [ well, I could see that if we shift a bunch of Apache functionality into APRUTIL, then we might see more Apache folks want commit access to work on the stuff. ] Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr apr_common.m4 hints.m4
On Tue, Nov 28, 2000 at 09:31:54PM -, [EMAIL PROTECTED] wrote:
rbb 00/11/28 13:31:53
Modified:src acinclude.m4 configure.in
.apr_common.m4 hints.m4
Added: src hints.m4
Log:
Split the hints file into two files, one in APR and one in Apache. The APR
hints file just sets build variables, the Apache hints file just sets
Apache variables. This is meant to clean up parts of APR, so that they
don't include Apache information.
...
--- apr_common.m4 2000/11/02 05:01:08 1.7
+++ apr_common.m4 2000/11/28 21:31:52 1.8
...
+dnl
+dnl APR_DOEXTRA
+dnl
+dnl Handle the use of EXTRA_* variables.
+dnl Basically, EXTRA_* vars are added to the
+dnl current settings of their parents. We
+dnl can expand as needed. This is ugly
+dnl
+AC_DEFUN(APR_DOEXTRA, [
+ for i in CFLAGS LDFLAGS LIBS
+ do
+eval APR_TMP=\$EXTRA_$i
+if test -n $APR_TMP; then
+ eval $i=\\$$i $APR_TMP\
+ eval export $i
+ eval unset EXTRA_${i}
+ eval export EXTRA_${i}
+fi
+ done
+])
I see that this came from apr/hints.m4, but I don't understand what it is
really doing here. What is this extra magic?
AFAIK, all we need to do is set the variables, and that is that. No fancy
export or anything.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/test testargs.c
[EMAIL PROTECTED] writes: gstein 00/11/28 23:41:27 Modified:include apr_getopt.h misc/unix getopt.c test testargs.c Log: Add an extra const into the getopt functions. We never attempt to modify any of the data, so the const is proper. This also allows clients to pass const data in. Please get http_main.c to compile without warnings again. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: SHA1 and Base64
--- Greg Stein [EMAIL PROTECTED] wrote: Well, it has been suggested that we create a new APR utility library. The discussion on that *just* opened today. It looks like we have several +1 on the concept, and I posted an outline of my thoughts on it. It's cool with me. That thread started while I was writing my email. =-) In any case... what I'm saying is that your idea may have merit, but it is probably easier to start with just one more library and go from there. As long as somebody can figure out what to put in it, then that's cool. --Cliff __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Re: cvs commit: apr apr_common.m4 hints.m4
On Wed, 29 Nov 2000, Greg Stein wrote:
On Tue, Nov 28, 2000 at 09:31:54PM -, [EMAIL PROTECTED] wrote:
rbb 00/11/28 13:31:53
Modified:src acinclude.m4 configure.in
.apr_common.m4 hints.m4
Added: src hints.m4
Log:
Split the hints file into two files, one in APR and one in Apache. The
APR
hints file just sets build variables, the Apache hints file just sets
Apache variables. This is meant to clean up parts of APR, so that they
don't include Apache information.
...
--- apr_common.m4 2000/11/02 05:01:08 1.7
+++ apr_common.m4 2000/11/28 21:31:52 1.8
...
+dnl
+dnl APR_DOEXTRA
+dnl
+dnl Handle the use of EXTRA_* variables.
+dnl Basically, EXTRA_* vars are added to the
+dnl current settings of their parents. We
+dnl can expand as needed. This is ugly
+dnl
+AC_DEFUN(APR_DOEXTRA, [
+ for i in CFLAGS LDFLAGS LIBS
+ do
+eval APR_TMP=\$EXTRA_$i
+if test -n $APR_TMP; then
+ eval $i=\\$$i $APR_TMP\
+ eval export $i
+ eval unset EXTRA_${i}
+ eval export EXTRA_${i}
+fi
+ done
+])
I see that this came from apr/hints.m4, but I don't understand what it is
really doing here. What is this extra magic?
AFAIK, all we need to do is set the variables, and that is that. No fancy
export or anything.
Unfortunately, as Jim found when he first did this stuff, Autoconf doesn't
use the EXTRA_* variables, so this is a bit of a hack.
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
---
Re: new APR package
On Wed, Nov 29, 2000 at 07:59:41AM -0800, [EMAIL PROTECTED] wrote: On Tue, 28 Nov 2000, Brian Behlendorf wrote: On Tue, 28 Nov 2000, Greg Stein wrote: Okay... we seem to have some general agreement to make a non-core APR package that contains the purely portable items. With that in mind, here are my rough ideas/notes on this: *) create a new CVS module: /home/cvs/aprutil [ other suggested names? aprkitchensink? :-) ] [ I'll refer to it as APRUTIL for this message's purposes... ] Would /home/cvs/apr-util be OK? That would save me some structural foo with mailing lists all. Is a separate dev cvs list desired? I was going to suggest /home/cvs/apr/util, in other words, make this a sub project of APR for now, and split it to it's own CVS repository later. Regardless, the dev and cvs mailing lists should be APR's, this should not have it's own mailing lists yet. Think of this as an APR sister-project. Let's make it a true sister project, rather than trying to split it later. If we defer the split, then we just end up with a large Attic. If we're starting from scratch, then the old difference between a new sister CVS module and a sub-project is that the former is where we want to be already. But I definitely agree re: mailing lists. === Does anybody have any issue with having Brian spin up a new CVS module named apr-util? Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr apr_common.m4 hints.m4
+AC_DEFUN(APR_DOEXTRA, [
+ for i in CFLAGS LDFLAGS LIBS
+ do
+eval APR_TMP=\$EXTRA_$i
+if test -n $APR_TMP; then
+ eval $i=\\$$i $APR_TMP\
+ eval export $i
+ eval unset EXTRA_${i}
+ eval export EXTRA_${i}
+fi
+ done
+])
Unfortunately, as Jim found when he first did this stuff, Autoconf doesn't
use the EXTRA_* variables, so this is a bit of a hack.
Ah. I think I understand. Wouldn't the above be simpler and more obvious if
we wrote it like:
AC_DEFIN(APR_DOEXTRA, [
CFLAGS=$CFLAGS $EXTRA_CFLAGS
EXTRA_CFLAGS=
LDFLAGS=$LDFLAGS $EXTRA_LDFLAGS
EXTRA_LDFLAGS=
LIBS=$LIBS $EXTRA_LIBS
EXTRA_LIBS=
])
Presuming the above works as expected, then I'd like to change the code.
The docs really explain what is happening, and this will allow us to add
more EXTRA_ options later really cleanly.
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
---
Re: cvs commit: apr apr_common.m4 hints.m4
[EMAIL PROTECTED] wrote: Ah. I think I understand. Wouldn't the above be simpler and more obvious if we wrote it like: AC_DEFIN(APR_DOEXTRA, [ CFLAGS=$CFLAGS $EXTRA_CFLAGS EXTRA_CFLAGS= LDFLAGS=$LDFLAGS $EXTRA_LDFLAGS EXTRA_LDFLAGS= LIBS=$LIBS $EXTRA_LIBS EXTRA_LIBS= ]) Presuming the above works as expected, then I'd like to change the code. The docs really explain what is happening, and this will allow us to add more EXTRA_ options later really cleanly. These should be exported in APRVARS, too. -- Brane ibej home: [EMAIL PROTECTED] http://www.xbc.nu/brane/ work: [EMAIL PROTECTED] http://www.hermes-softlab.com/ ACM: [EMAIL PROTECTED]http://www.acm.org/
Re: cvs commit: apr apr_common.m4 hints.m4
On Wed, Nov 29, 2000 at 09:46:51PM +0100, Branko Cibej wrote: [EMAIL PROTECTED] wrote: Ah. I think I understand. Wouldn't the above be simpler and more obvious if we wrote it like: AC_DEFIN(APR_DOEXTRA, [ CFLAGS=$CFLAGS $EXTRA_CFLAGS EXTRA_CFLAGS= LDFLAGS=$LDFLAGS $EXTRA_LDFLAGS EXTRA_LDFLAGS= LIBS=$LIBS $EXTRA_LIBS EXTRA_LIBS= ]) Presuming the above works as expected, then I'd like to change the code. The docs really explain what is happening, and this will allow us to add more EXTRA_ options later really cleanly. These should be exported in APRVARS, too. We've got EXTRA_CPPFLAGS, EXTRA_CFLAGS, and EXTRA_LIBS in there today. Missing the LDFLAGS stuff. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr apr_common.m4 hints.m4
Greg Stein wrote: I see that this came from apr/hints.m4, but I don't understand what it is really doing here. What is this extra magic? AFAIK, all we need to do is set the variables, and that is that. No fancy export or anything. Unfortunately, as Jim found when he first did this stuff, Autoconf doesn't use the EXTRA_* variables, so this is a bit of a hack. Ah. I think I understand. Wouldn't the above be simpler and more obvious if we wrote it like: AC_DEFIN(APR_DOEXTRA, [ CFLAGS=$CFLAGS $EXTRA_CFLAGS EXTRA_CFLAGS= LDFLAGS=$LDFLAGS $EXTRA_LDFLAGS EXTRA_LDFLAGS= LIBS=$LIBS $EXTRA_LIBS EXTRA_LIBS= ]) Presuming the above works as expected, then I'd like to change the code. I need to check what it's being done for, but the reason for the exports and the evals is because you need to protect the use of the vars until you actually need to use them. Recall that autconf simply cuts and pastes, so it will see what they are defined as at that time, and use those values. The evals' are there to ensure that happens. The exports were to make sure that any sub-configures picked up the changes, something we most likely need in APR anyway (eg: MM?). I don't think the above will work, at least it won't in the original way we were using it. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Casanova will have many weapons; To beat him you will have to have more than forks and flatulence.
