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