>> + if (rv == APR_SUCCESS) {
>> + return newSViv((int)length);
>> + }
>> +
>> + return &PL_sv_undef;
>> +}
>
>
> won't it be better to die if it fails and stick rv into [EMAIL PROTECTED] e.g. if you
> try to read a bucket which has no data? Just thinking aloud here, we
> have many places where don't quite handle error codes, but I tend to at
> least stick XXX in them and hopefully figure it out when we get first
> failures.
yeah, I wasn't quite sure what to do here. I didn't like the idea of
length() returning an $rv and populating a $length argument, since it seemed
more useful to simply have it return the length. but I'm deviating from the
API here, so I dunno.
as for sticking the rv in $@, I don't see that being useful, since it's just
an APR_ status code.
> In the test script you end up allocating memory for 300k instead of
> 200k, just to throw 100k of it right away. a big waste.
hmm, the length passed ends up being allocated? I was just trying to
simulate a user that used a big number since the size was unknown (and who
didn't know about length())
>
> I don't think flatten is effective, as it has to go through all the
> bucket twice - once because you need to figure out its length, second
> time to slurp data.
I was getting that feeling as I implemented it - the dependency on the
length made it seem less than optimal for a "slurp" mode.
>
> pflatten doesn't require that. It does all the work for you. You really
> want to use flatten only when you want to flatten only not more than X
> bytes, I think.
yeah, that's how it's used, I noticed.
>
> with pflatten you do:
>
> char *buffer;
> apr_size_t bufsiz = HUGE_STRING_LEN;
> rc = apr_brigade_pflatten(bb, &buffer, &bufsiz, pool);
>
> buffer is probably PVX(sv_buf), after you forced it into PV.
> and after that set the pv's length slot to bufsize.
> and then just stash that buffer into a new SV or pass.
yup, pretty much like the way I did it before (which was stolen from
APR::Socket:recv)
> More effecient
> and simpler for the end user (though requires the dreaded pool object)
yeah, that's the problem - requiring a pool is turning this all into less of
a shortcut. but just because it takes more effort doesn't mean we shouldn't
open them both up anyway.
so, I'll do them both and whip up a patch for the Apache::Request docs that
use pflatten() instead.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
