apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <rbl...@gmail.com>
Subject Re: APR: Portable across Operating Systems, or Libraries?
Date Fri, 23 Jan 2009 12:24:47 GMT
Why do you want to jettison "edge platforms"?  The original goal was to keep
HTTPd as portable as 1.3 was, which meant APR had to support mainframes,
OS/2, etc.  All of those edge platforms are what made APR challenging to
create and maintain, but they also provide a lot of value for the people who
want their code to work on mainframes, but don't want to write their own
portability library.

Removing this support takes away a web server (at the very least) from
openBeOS, OS400, OS/2, etc.  While these platforms may not be mainstream
these days, dropping support for them from HTTPd (the natural result of
dropping support from APR) seems like a decision that can only be made after
discussion with APR's users, not the developers of APR itself.

Just a few thoughts from the gallery.

Ryan

Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com


On Fri, Jan 23, 2009 at 6:26 AM, Graham Leggett <minfrin@sharp.fm> wrote:

> Greg Stein wrote:
>
>  When thinking about 2.0, I'm having a hard time with the idea of
>> pulling apr-util into regular apr. We've got a lot of stuff in
>> apr-util that has nothing to do with "Portability". Basically, I see
>> apr-util doing one of two types of things:
>>
>> * common API to access functionality (dbd, ldap, crypto)
>> * useful functionality built on APR
>>
>> I think it would be great if we could concentrate on just a core APR
>> that offers OS portability, and that we also jettison "edge" platforms
>> (keep posix and windows only). And that we trim out functionality
>> (i.e. apr_tables) that have nothing to do with portability (tho we
>> keep pools as a lifetime mgmt capability for OS objects).
>>
>> Thoughts?
>>
>
> I think both apr and apr-util are still both based on the idea of
> "portability".
>
> In apr, the focus is on making individual or "small" sets of functions
> available in a portable way, while the focus of apr-util is to have "large"
> or "complex" sets of functionality (access a database, access an LDAP
> server, encrypt a string) available in a portable way.
>
> That said you're right that some parts of it, like tables, fall into the
> category of "useful stuff" rather than "portable stuff". Perhaps an idea
> could be to move the "useful stuff" into (a want for a better name)
> apr-useful, which would be the "useful stuff" library built on top of the
> portability provided by apr.
>
> Regards,
> Graham
> --
>

Mime
View raw message