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." <[EMAIL PROTECTED]> 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/
