apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: SHA1 and Base64
Date Wed, 29 Nov 2000 02:45:57 GMT

--- "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:


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

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.)

   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

I say "as low as" because I think there should be four layers:

   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.

  (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.

  (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
  (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?


Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.

View raw message