Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes: [...]
Still, once user tries to modify the data, what happens to meta-data? When COW is performed, does it copy the whole thing or just whatever was pointed by SvCUR?
Doesn't matter. The point is that if there's an Apache::Request::Table that subclasses APR::Table, it doesn't have to *reimplement everything* in APR::Table. It can just fixup the return values before they are returned, like this: package Apache::Request::Table; use base 'APR::Table'; sub get { if (wantarray) { return map {fixup_sv($_)} &APR::Table::get; } else { return fixup_sv(scalar &APR::Table::get); } } The only XSUB we'd need to maintain in the subclass is fixup_sv(). But if APR::Table uses newSVpvn, Apache::Request::Table would need to *completely reimplent all* the APR::Table XSUBS.
So we really are concerned about FETCH, and never about STORE?
For APR::Tables, that's right- the copy/merge callbacks (which I'm confident apr will adopt) will take care to add some appropriate
metadata during STORE.
cool
What if you use mpxs_apr_table_do to fixup the elements on the first
FETCH? Would that be a bad approach?
Not sure what you have in mind.
you can run filter on all pairs in the table, see t/response/TestAPR/table.pm
The problem is that I still don't understand what do you need that meta data for and how is it used.
1) the perl-glue for apreq will finally be able to handle embedded nul characters,
2) we can duplicate CGI.pm's overloading of params, since file-uploads
are just params with a non-NULL bucket-brigade attached.
3) we can do lots of cool stuff with cookie values, too.
Any examples of how is it used?
Here's another idea that is safe, and should work for everyone: just add a magic pointer to the original (char *) and keep using newSVpv():
MP_INLINE static SV *mpxs_apr_table_str_2sv(pTHX_ const char *str)
{
SV *sv = newSVpv(str, 0);
sv_magic(sv, Nullsv, PERL_MAGIC_ext, str, 0);
return sv_2mortal(sv);
}
This way Apache::Request::Table can get at the original string via mg->mg_ptr, so it just needs to maintain an sv_fixup XSUB.
Can you ensure that apr won't relocate the string? why not pointing at the newly copied sv's PV?
I can't see where the meta data is in str. Is it before str?
If this looks ok, I'll try to conjure up a patch :-)
--
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
