You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by rb...@covalent.net on 2000/11/28 01:26:46 UTC
SHA1 and Base64
The new-httpd group has discussed putting SHA1 and Base 64 encoding
schemes into APR. This has met with some resistance in the past, but it
really needs to be discussed and decided here. So, can these go in the
passwd directory of APR?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SHA1 and Base64
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 28, 2000 at 12:59:06PM -0800, rbb@covalent.net wrote:
>
> > > To me, all of this speaks in favour of creating /another/ library for
> > > such not-sctrictly-portability stuff, and slowly moving the generic bits
> > > out of APR. For all I care this could mean splitting APR into a core and
> > > utility library, but keeping them conceptually together.
> > >
> > > How much sense that makes is another matter.
> >
> > I'm fine with that.
>
> Same here.
Woah, woah, woah... did we just agree?
;-)
--
Greg Stein, http://www.lyra.org/
Re: SHA1 and Base64
Posted by Branko Čibej <br...@xbc.nu>.
rbb@covalent.net wrote:
>>> To me, all of this speaks in favour of creating /another/ library for
>>> such not-sctrictly-portability stuff, and slowly moving the generic bits
>>> out of APR. For all I care this could mean splitting APR into a core and
>>> utility library, but keeping them conceptually together.
>>>
>>> How much sense that makes is another matter.
>>
>> I'm fine with that.
>
>
> Same here.
Well! The Judgement of Solomon, then: Let's split the baby. :-)
--
Brane Čibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: SHA1 and Base64
Posted by rb...@covalent.net.
> > To me, all of this speaks in favour of creating /another/ library for
> > such not-sctrictly-portability stuff, and slowly moving the generic bits
> > out of APR. For all I care this could mean splitting APR into a core and
> > utility library, but keeping them conceptually together.
> >
> > How much sense that makes is another matter.
>
> I'm fine with that.
Same here.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SHA1 and Base64
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 28, 2000 at 09:05:52PM +0100, Branko Cibej wrote:
>...
> This is a tough question. On the one hand, Greg's right that your
> arguments can effectively be used in favour of putting any and all
> "useful" utility functions into ARP. On the other hand, one might just
> as easily use Greg's arguments to throw pools out of APR and put them in
> a separate utility library ...
Currently, all pool implementations use malloc(), but I could see a Windows
specific version that uses native Win32 memory mgmt functions to speed
things up. There could also be tradeoffs made inside there to get optimum
memory allocation speed (e.g. always use malloc, maybe use sbrk on some
platforms, use a third-party custom allocator for some platforms cuz their
malloc blows chunks, ...)
> To me, all of this speaks in favour of creating /another/ library for
> such not-sctrictly-portability stuff, and slowly moving the generic bits
> out of APR. For all I care this could mean splitting APR into a core and
> utility library, but keeping them conceptually together.
>
> How much sense that makes is another matter.
I'm fine with that.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: SHA1 and Base64
Posted by Branko Čibej <br...@xbc.nu>.
rbb@covalent.net wrote:
> Greg and I are pretty clear on our definition of what does and does not
> belong in APR, does anybody else have an opinion? We need to get this
> decided.
This is a tough question. On the one hand, Greg's right that your
arguments can effectively be used in favour of putting any and all
"useful" utility functions into ARP. On the other hand, one might just
as easily use Greg's arguments to throw pools out of APR and put them in
a separate utility library ...
To me, all of this speaks in favour of creating /another/ library for
such not-sctrictly-portability stuff, and slowly moving the generic bits
out of APR. For all I care this could mean splitting APR into a core and
utility library, but keeping them conceptually together.
How much sense that makes is another matter.
--
Brane Čibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: SHA1 and Base64
Posted by rb...@covalent.net.
> > I just don't understand this argument, I'm sorry. The whole point of APR
> > is to help people port their code to different platforms.
>
> Key word: PORT
>
> APR isn't a kitchen sink of functionality. It is a portability library.
>
> Didn't we just get done talking about this?
We just got done discussing the mission statement, which tells us what we
are going after, but doesn't list what those features are. :-)
> > APR never uses tables, at least the only place I see tables is in the
> > tables.c file.
>
> I have no problem being consistent. If tables aren't used, then yah... I'm
> fine with seeing them moved out of APR. Hell, if it weren't for all the
> legacy Apache code that used tables, I'd dump them in favor of apr_hash_t.
No. Its not just legacy code. Tables and hashes have two different
purposes, and trying to force one when the other is the correct solution
is just wrong.
> > APR only uses arrays in the canonical stuff, and I'm pretty sure it could
> > be removed easily.
>
> Well, we shouldn't make our life difficult just to toss a type. But if the
> arrays don't make sense, then yah. I have no problem with tossing them, too.
I'm pretty sure the canonical stuff can be done with just a straight
array, and we can ignore the Apache array_header stuff.
But I'm not for getting rid of these types. They help people to write
portable programs. These are all routines that are useful on any
platform, regardless of whether they are inherently portable or not.
> > I just took a quick look at NSPR, which is what APR was originally based
> > on, and they have a linked list structure. Linked lists are also
> > inherently portable.
>
> So? That's NSPR. We're talking about APR here :-)
Yes, but we have always looked to NSPR for help. The whole interval_time
stuff is a direct translation from NSPR. You can't just start ignoring
NSPR just because you don't like it.
> > What is there now, is database
> > code, which in my mind is at a higher level than SHA1 and Base64.
>
> 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.
Greg, please define portability. According to a dictionary it is:
3.Computer Science. Relating to or being software that can run on two
or more kinds of computers or with two or more kinds of operating
systems.
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.
Greg and I are pretty clear on our definition of what does and does not
belong in APR, does anybody else have an opinion? We need to get this
decided.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SHA1 and Base64
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 27, 2000 at 09:57:53PM -0800, rbb@covalent.net wrote:
> On Mon, 27 Nov 2000, Greg Stein wrote:
> > On Mon, Nov 27, 2000 at 04:26:46PM -0800, rbb@covalent.net wrote:
> > > The new-httpd group has discussed putting SHA1 and Base 64 encoding
> > > schemes into APR. This has met with some resistance in the past, but it
> > > really needs to be discussed and decided here. So, can these go in the
> > > passwd directory of APR?
> >
> > <IMO>
> >
> > They do nothing for portability. They should go into the new "aputil"
> > library in Apache. If we see a big demand for utility functions (rather than
> > portability stuff), then we can extract aputil.
> >
> > </IMO>
> >
> > Heck, I never thought the inclusion of MD5 was appropriate. That has nothing
> > to do with portability either, and the other parts of APR don't need it.
> > About the only reason is that the MD5 code does translation at the same
> > time. But that is still just a layer on top of APR... nothing in APR uses
> > MD5 itself.
> >
> > (hashes, tables, arrays are portable, but APR itself needs those)
>
> I just don't understand this argument, I'm sorry. The whole point of APR
> is to help people port their code to different platforms.
Key word: PORT
APR isn't a kitchen sink of functionality. It is a portability library.
Didn't we just get done talking about this?
> If you want to
> get rid of any type that isn't needed by APR itself, then please lets be
> consistent.
>
> APR never uses tables, at least the only place I see tables is in the
> tables.c file.
I have no problem being consistent. If tables aren't used, then yah... I'm
fine with seeing them moved out of APR. Hell, if it weren't for all the
legacy Apache code that used tables, I'd dump them in favor of apr_hash_t.
> APR only uses arrays in the canonical stuff, and I'm pretty sure it could
> be removed easily.
Well, we shouldn't make our life difficult just to toss a type. But if the
arrays don't make sense, then yah. I have no problem with tossing them, too.
> APR doesn't currently use hashes, but there is a comment that the userdata
> should be replaced with a hash.
It really should. I'm probably going to change it within the next few days
because I'd like to use non-string keys for some userdata.
> It is my own opinion that SHA1 and Base64 encoding are inherently
> portable, but that doesn't make it a non-issue for portability
> run-times. These are features that useful to applications besides
> servers.
Useful != assisting-with-porting
> I just took a quick look at NSPR, which is what APR was originally based
> on, and they have a linked list structure. Linked lists are also
> inherently portable.
So? That's NSPR. We're talking about APR here :-)
> These don't belong in aputil, for one thing aputil has never been defined
> as far as what it is. I had always envisioned it as more of a user-agent
> type of library, which handled URI issues.
You guys extracted much of that code from Apache and created a library
called "apua". That is not the same as yanking the non-HTTP-server specific
stuff from Apache and placing it into aputil.
Yes, aputil isn't defined YET, but the discussions over the past year about
creating a library have all centered around "move src/ap/ into
lib/something". That something is now aputil.
> What is there now, is database
> code, which in my mind is at a higher level than SHA1 and Base64.
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.
> The question we really need to decide, is what makes code an issue for a
> portable run-time. Is it that the code is different on different
> platforms, or that the code is useful for many different kinds of programs
> and has some potential issues on different machines.
>
> I believe the latter is the correct definition for a portable run-time,
> and that SHA1 and Base64 encoding fit this definition.
By this argument, we should also include compression code, SSL encryption, a
DBM implementation, XML utilities, hooks, buckets, and some date formatting
and parsing functions. :-)
All of those are used in Apache, and I could see using all of them in SVN.
But I don't want to see all that lumped into APR. It doesn't suit APR's
goals of assisting with portability.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: SHA1 and Base64
Posted by rb...@covalent.net.
On Mon, 27 Nov 2000, Greg Stein wrote:
> On Mon, Nov 27, 2000 at 04:26:46PM -0800, rbb@covalent.net wrote:
> >
> > The new-httpd group has discussed putting SHA1 and Base 64 encoding
> > schemes into APR. This has met with some resistance in the past, but it
> > really needs to be discussed and decided here. So, can these go in the
> > passwd directory of APR?
>
> <IMO>
>
> They do nothing for portability. They should go into the new "aputil"
> library in Apache. If we see a big demand for utility functions (rather than
> portability stuff), then we can extract aputil.
>
> </IMO>
>
> Heck, I never thought the inclusion of MD5 was appropriate. That has nothing
> to do with portability either, and the other parts of APR don't need it.
> About the only reason is that the MD5 code does translation at the same
> time. But that is still just a layer on top of APR... nothing in APR uses
> MD5 itself.
>
> (hashes, tables, arrays are portable, but APR itself needs those)
I just don't understand this argument, I'm sorry. The whole point of APR
is to help people port their code to different platforms. If you want to
get rid of any type that isn't needed by APR itself, then please lets be
consistent.
APR never uses tables, at least the only place I see tables is in the
tables.c file.
APR only uses arrays in the canonical stuff, and I'm pretty sure it could
be removed easily.
APR doesn't currently use hashes, but there is a comment that the userdata
should be replaced with a hash.
It is my own opinion that SHA1 and Base64 encoding are inherently
portable, but that doesn't make it a non-issue for portability
run-times. These are features that useful to applications besides
servers.
I just took a quick look at NSPR, which is what APR was originally based
on, and they have a linked list structure. Linked lists are also
inherently portable.
These don't belong in aputil, for one thing aputil has never been defined
as far as what it is. I had always envisioned it as more of a user-agent
type of library, which handled URI issues. What is there now, is database
code, which in my mind is at a higher level than SHA1 and Base64.
The question we really need to decide, is what makes code an issue for a
portable run-time. Is it that the code is different on different
platforms, or that the code is useful for many different kinds of programs
and has some potential issues on different machines.
I believe the latter is the correct definition for a portable run-time,
and that SHA1 and Base64 encoding fit this definition.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SHA1 and Base64
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 27, 2000 at 04:26:46PM -0800, rbb@covalent.net wrote:
>
> The new-httpd group has discussed putting SHA1 and Base 64 encoding
> schemes into APR. This has met with some resistance in the past, but it
> really needs to be discussed and decided here. So, can these go in the
> passwd directory of APR?
<IMO>
They do nothing for portability. They should go into the new "aputil"
library in Apache. If we see a big demand for utility functions (rather than
portability stuff), then we can extract aputil.
</IMO>
Heck, I never thought the inclusion of MD5 was appropriate. That has nothing
to do with portability either, and the other parts of APR don't need it.
About the only reason is that the MD5 code does translation at the same
time. But that is still just a layer on top of APR... nothing in APR uses
MD5 itself.
(hashes, tables, arrays are portable, but APR itself needs those)
This all falls back to the "portability vs. utility" argument.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/