apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: Re-architecture for 2.0 tree
Date Thu, 20 Jan 2005 10:31:52 GMT
On Wednesday 19 January 2005 18:33, Ryan Bloom wrote:

> One of my biggest mistakes when initially designing APR was that I
> forced each platform to have completely distinct implementations for
> simple functions if the structures were distinct.  This has led to a
> great amount of duplicate code in the library, and makes it harder to
> see where the differences between the platforms truly are.  I would
> love to see APR 2.0 solve this problem.

I don't think the architecture is inherently wrong.  Duplicated code suggests
rather that the platform-layer is too big.

> My idea is simple enough, share as much of the structures as possible
> between platforms.  This allows the functions that act on those
> structures to be common code.  To do this, the basic format of our
> structures have to change, so that they look more like the apr_poll_t
> structure.  I'll use files as an example (forgive the syntax):

If I understand you aright, you mean factoring out common code from the
platform layer into a new platform-independent layer, yesno?   I think that
makes sense.

> typedef struct arch_file arch_file;
> typedef struct apr_file_t {
>     apr_pool_t *p;
>     char *name;
>     int eof_hit;
>     ....
>     union
>     apr_arch_file_t *arch_file;
> } apr_file_t;

Good so far: an APR-ised indirection for a platform-dependent entry
(except - what's that "union" doing in there?)

> In another header file:
> #ifdef WIN32
> struct arch_file {
>     HANDLE filedes;
> }
> #else
> struct arch_file {
>     int filedes;
> }
> #endif

I'm not so keen on that.  A proliferation of #ifdefs in actual code
are harder to work with (some of us still use tools like grep:-)
A minor reorganisation like

#ifdef WIN32
#include "win32stuff.h"
#else
#include "posixstuff.h"
#endif

with a level of granularity TBD serves to define the interface of the
platform-layer much more clearly.

> Thoughts, comments, critisms, questions?

My apr_dbd code deals with a somewhat analagous problem where the
"platform" is the backend database.  It deals with that in a similar way,
using incomplete types for the platform-dependent structs.

It also dlloads the drivers (provided APR_HAS_DSO).  That isn't relevant to
most of APR as it stands now (except perhaps APR_DBM), but could become
the norm if - as has been suggested - we're going to make it a much more
pluggable framework and accommodate third-party extensions, apr-java, etc.

-- 
Nick Kew

Mime
View raw message