On Thu, 6 Dec 2001, Stas Bekman wrote: > but I guess I don't understand something: why do we need to use > APR::File->open? What's wrong with perl's open()? I've it working > already. If you don't use perl's open() do you also imply that we have > to use $fh->close, $fh->seek and so on, using APR arguments? What's the > point of having PerlIO layer at all?
my interest in having an APR::File->open() was so we can pass in the args directly rather than jump through hoops to convert the perl sugar. it would end up calling apr_file_open exactly the same way the builtin open would. but then again, you are implementing APR::PerlIO/PerlIO::APR not APR::File, so forget APR::File->open. > I've basic tests working using a pure perl syntax and apr calls as its > internals. Here is a snippet from the test: > > open my $fh, "<:APR", $file > or die "Cannot open $file for reading: $!"; > > open my $dup_fh, "<&:APR", $fh > or die "Cannot dup $file for reading: $!"; > close $fh; > > my $received = <$dup_fh>; > close $dup_fh; cool. > so the only thing it misses is $r|$s, which can be: > > open my $fh, $r, ... that should be easy with modperl_sv2pool, right? > I'm not sure how to handle the best the forwarding of any errors from > APR's side to Perl side. I don't think it's possible to convert APR's > errno into Perl's errno, without a *lot* of hassle. what's the best way > to go? there is something in apr to get the errno out of apr_status_t, don't remember what it is though. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]