httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <da...@jetnet.co.uk>
Subject Re: Apache 2.0 alpha. (again) :)
Date Tue, 21 Mar 2000 10:25:54 GMT
Yeah that sounds OK.  As we're using APR as an uderpinning layer 
anyway, then moving functions from APR
and back into an ap_ file doesn't actually involve very much effort 
anyway.  There are some things that might want to stay there (such as 
the getpass implementations) as they have different implementations for 
different systems, but again that's an easy matter to fix (apr_getpass 
in APR and ap_getpass using apr_getpass in Apache??)

Again, my gut is that we do it on a case by case basis and evolve the 
philosophy and the exact borderline over time.

d.
>Yah, mm was a bad example. Logically, I see it as a part of APR
>(especially given that it isn't as portable, as you note).
>
>But on other things which are inherently portable, it sounds like we
>agree (e.g. MD5 and SHA1 hashes, arrays and tables, log handling, or 
cache
>mgmt). Some portions go above or below APR; it kind of depends on what 
APR
>itself needs (such as arrays/tables).
>
>For the stuff that APR needs itself, I might even forego the clean
>separation and just drop them into APR. Have APR as a standalone, 
layer
>one library on that, and then apps above that. Throwing yet another 
teeny
>library under APR as a dependent of APR seems to be pushing the 
separation
>a bit too far (but I wouldn't mind if it got large enough).
>
>Cheers,
>-g
>
>On Tue, 21 Mar 2000, David Reid wrote:
>
>> Greg,
>> 
>> Agreed but we need to be careful.  mm presently only works on Unix &
 BeOS.
>> OS/2 has it's own implementation and so probably will windows, so 
APR makes
>> sense for these, no?
>> 
>> If something is non-specific and works out of the box on all 
platforms then
>> I see no need to add it to APR and having it as a separate library 
is a
>> better solution.  We just need to look at them when they are 
suggested.
>> 
>> david
>> 
>> > 2) functions which use no OS facilities and are (therefore) 
inherently
>> >    portable.
>> >
>> >
>> > When APR was started, I believed it to be #1 only. The other 
utility
>> > functions are just that -- utilities. They don't serve to make 
programs
>> > more portable. All you're providing is packaging, not portability.
>> >
>> > Rather than see APR become a big bag of unfocused bits, I'd rather 
see it
>> > become stuff to make things portable. The "general" stuff should 
go into
>> > its own package and compete on merits against things like mhash, 
mm, glib
>> > (not to be confused with glibc), and similar libraries/toolsets.
>> >
>> > Cheers,
>> > -g
>> >
>> > --
>> > Greg Stein, http://www.lyra.org/
>> >
>> >
>> 
>
>-- 
>Greg Stein, http://www.lyra.org/
>
>

Mime
View raw message