On 19 Jun 2001, Jeff Trawick wrote:
> > +#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 :)
Yeah... sadly, I was just trying to make them fit on one line in places
where they're used. ;-) I'll add the extra _.
> 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
Hmm... well, not necessarily. Just because it has a file descriptor in it
doesn't mean that it behaves like a file bucket in any OTHER way. All the
flag means is that there exists a file descriptor in the bucket data
structure at a particular offset that you can use sendfile on. Whether it
would be MMAPed upon read or whatever... well, that's a different flag, I
think. No?
> a couple of really tiny nits about APR_BUCKET_FLAGALLFNS...
>
> . ALLFNS doesn't mean all functions, it just means all of the cool
> things
No, it means all functions. destroy() and read() are required, so if you
have the other three, you have all five of them.
> . 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
Yeah, I guess... the lines just become prohibitively long. But you're
right that it could cause problems if we added to it later. <sigh> Well,
I'll see what I can do... I don't suppose anyone would agree to a
"APR_BUCKET_FLAGTHREEOPTFNS" or something like that?
> 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
It does mention that (well, actually, the APR_BUCKET_SUPPORTS_SENDFILE()
documentation mentions it... I guess a @see is appropriate at least). An
accessor function is not needed; all you have to do is just pretend that
it's a FILE bucket. It goes something like this:
if (APR_BUCKET_SUPPORTS_SENDFILE(e)) {
apr_bucket_file *f = e->data;
apr_sendfile(sock, f->fd, ...);
}
Easy, huh?
--Cliff
--------------------------------------------------------------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
