apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: SHA1 and Base64
Date Wed, 29 Nov 2000 09:06:06 GMT
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.


On Tue, Nov 28, 2000 at 06:45:57PM -0800, Cliff Woolley wrote:
> --- "William A. Rowe, Jr." <wrowe@rowe-clan.net> 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/

View raw message