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
