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.

Cheers,
-g

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/

Mime
View raw message