Cliff Woolley <[EMAIL PROTECTED]> writes:
> +/**
> + * apr_bucket_type_t flags
> + */
> +#define APR_BUCKET_FLAGNONE 0x00000000
> +#define APR_BUCKET_FLAGSETASIDE 0x00000001
> +#define APR_BUCKET_FLAGSPLIT 0x00000002
> +#define APR_BUCKET_FLAGCOPY 0x00000004
> +#define APR_BUCKET_FLAGSENDFILE 0x00000010
> +#define APR_BUCKET_FLAGMETADATA 0x00000100
> +#define APR_BUCKET_FLAGALLFNS
> \
> + (APR_BUCKET_FLAGSETASIDE | APR_BUCKET_FLAGSPLIT |
> APR_BUCKET_FLAGCOPY)
how about a '_' after FLAG? as long as they are already we might as
well make them a little more readable :)
re APR_BUCKET_FLAGSENDFILE: all that matters is that the bucket
represents an apr_file_t... whether or not somebody is going to use
apr_sendfile() or something else shouldn't be important to the bucket
code, should it? perhaps it should be renamed to APR_BUCKET_FLAGFILE
a couple of really tiny nits about APR_BUCKET_FLAGALLFNS...
. ALLFNS doesn't mean all functions, it just means all of the cool
things
. ALLFNS will surely change in the future, but what is the way to get
the bucket types updated appropriately? I suspect that if we do
away with ALLFNS and instead "spell it out" in the bucket type
definitions it will be most obvious what to update
------/------
possible phase 2 change...
would it be bad to have an accessor function for the file descriptor?
otherwise, the doc for APR_BUCKET_FLAGSENDFILE should mention that if
the bucket has this flag then the apr_file_t * has to be at the magic
offset
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
