--- Begin Message ---
Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
> > Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> >>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
I still don't see how that's useful here. There's nothing
wrong with the data inside apr_table. It's the c2perl
translation (newSVpv) that's causing the lossage.
> >>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?
Nothing solid API-wise, since the perl API needs to be discussed on
apreq-dev. But given all the recent confusion on modperl@ over the
Cookie API, there's good reason to simplify the API. What I'd like to
do is push the idea of params & cookies of being _values_ with _objects_
attached to them, instead of the other way around (which is what we
do in apreq-1). So for example, if you want to get at the 'foo'
cookie, I'd rather write something like
my $jar = Apacke::Cookie->fetch($r); # ref(jar) = Apache::Cookie::Table
my $foo = $jar->{'foo'}; # $cookie_obj = tied $foo;
instead of the current monstrosity:
my $jar = Apache::Cookie->fetch;
my $cookie_obj = $jar->{'foo'};
my $foo = $cookie && $cookie_obj->value;
The '&&' test is both necessary and really fugly.
[...]
> > 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?
Yes- which was one of the key points of my original patch to apr_tables.
That's exactly the problem solved by the copier/merger callbacks.
> why not pointing at the newly copied sv's PV?
The copied SVPV is useless, since...
> I can't see where the meta data is in str. Is it before str?
Yes, the metadata is ALWAYS right before str! str is
pointer to the _end_ of an apreq struct
(str == param->v.data or str == cookie->v.data).
Patch attached- hopefully this will clarify the issues. Please comment.
Index: xs/APR/Table/APR__Table.h
===================================================================
RCS file: /home/cvspublic/modperl-2.0/xs/APR/Table/APR__Table.h,v
retrieving revision 1.9
diff -u -r1.9 APR__Table.h
--- xs/APR/Table/APR__Table.h 24 Aug 2002 17:15:58 -0000 1.9
+++ xs/APR/Table/APR__Table.h 5 Jun 2003 01:46:17 -0000
@@ -3,6 +3,17 @@
#define mpxs_APR__Table_DELETE apr_table_unset
#define mpxs_APR__Table_CLEAR apr_table_clear
+MP_INLINE static SV *mpxs_apr_table_str_2sv(pTHX_ const char *str)
+{
+ SV *sv;
+ if (str == NULL)
+ return &PL_sv_undef;
+
+ sv = newSVpv(str, 0);
+ sv_magic(sv, Nullsv, PERL_MAGIC_ext, str, 0);
+ return sv_2mortal(sv);
+}
+
typedef struct {
SV *cv;
apr_hash_t *filter;
@@ -35,8 +46,8 @@
SAVETMPS;
PUSHMARK(sp);
- XPUSHs(sv_2mortal(newSVpv(key,0)));
- XPUSHs(sv_2mortal(newSVpv(val,0)));
+ XPUSHs(mpxs_apr_table_str_2sv(aTHX_ key));
+ XPUSHs(mpxs_apr_table_str_2sv(aTHX_ val));
PUTBACK;
rv = call_sv(tdata->cv, 0);
@@ -58,7 +69,7 @@
SV *sub;
mpxs_table_do_cb_data_t tdata;
- mpxs_usage_va_2(table, sub, "$table->do(sub, [EMAIL PROTECTED])");
+ mpxs_usage_va_2(table, sub, "$table->do(subref, @keys)");
tdata.cv = sub;
tdata.filter = NULL;
@@ -127,41 +138,30 @@
return mpxs_APR__Table_NEXTKEY(aTHX_ tsv, Nullsv);
}
+static int mpxs_apr_table_do_get(void *data, const char *key, const char *val)
+{
+ dTHXa(data);
+ dSP;
+ XPUSHs(mpxs_apr_table_str_2sv(aTHX_ val));
+ PUTBACK;
+ return GIMME_V == G_ARRAY;
+}
+
static XS(MPXS_apr_table_get)
{
dXSARGS;
if (items != 2) {
- Perl_croak(aTHX_ "Usage: $table->get($key)");
+ Perl_croak(aTHX_ "Usage: APR::Table::get($table, $key)");
}
-
- mpxs_PPCODE({
- APR__Table t = modperl_hash_tied_object(aTHX_ "APR::Table", ST(0));
- const char *key = (const char *)SvPV_nolen(ST(1));
-
+ else {
+ apr_table_t *t = modperl_hash_tied_object(aTHX_ "APR::Table", ST(0));
+ const char *key = (const char *)SvPV_nolen(ST(1));
if (!t) {
XSRETURN_UNDEF;
}
-
- if(GIMME_V == G_SCALAR) {
- const char *val = apr_table_get(t, key);
-
- if (val) {
- XPUSHs(sv_2mortal(newSVpv((char*)val, 0)));
- }
- }
- else {
- const apr_array_header_t *arr = apr_table_elts(t);
- apr_table_entry_t *elts = (apr_table_entry_t *)arr->elts;
- int i;
-
- for (i = 0; i < arr->nelts; i++) {
- if (!elts[i].key || strcasecmp(elts[i].key, key)) {
- continue;
- }
- XPUSHs(sv_2mortal(newSVpv(elts[i].val,0)));
- }
- }
- });
-
+ XSprePUSH;
+ PUTBACK;
+ apr_table_do(mpxs_apr_table_do_get, aTHX, t, key, NULL);
+ }
}
Index: docs/api/APR/Table.pod
===================================================================
RCS file: /home/cvspublic/modperl-docs/src/docs/2.0/api/APR/Table.pod,v
retrieving revision 1.1
diff -u -r1.1 Table.pod
--- docs/api/APR/Table.pod 27 Jan 2003 04:05:12 -0000 1.1
+++ docs/api/APR/Table.pod 5 Jun 2003 01:46:18 -0000
@@ -40,17 +40,13 @@
tables.
The table's structure is somewhat similar to the Perl's hash
-structure, but allows multiply values for the same key. An access to
+structure, but allows multiple values for the same key. An access to
the records stored in the table always requires a key.
The key-value pairs are stored in the order they are added.
The keys are case-insensitive.
-However as of the current implementation if more than value for the
-same key is requested, the whole table is lineary searched, which is
-very inefficient unless the table is very small.
-
C<APR::Table> provides a L<TIE Interface|/TIE_Interface>.
See I<apr/include/apr_tables.h> in ASF's I<apr> project for low level
@@ -148,7 +144,7 @@
=item * do()
- $table->do(sub {[...]}, [EMAIL PROTECTED]);
+ $table->do(sub {[...]}, @filter);
Iterate over all the elements of the table, invoking provided
subroutine for each element. The subroutine gets passed as argument,
--
Joe Schaefer
--- End Message ---
