Re: apreq - apr-util
david reid wrote: While doing some work on mod_sparql I found that some of the functionality i had assumed we already had in apr-util was actually available in apreq. Further examination revealed various parts of the library code that I feel really belong in apr-util. I talked briefly with joes and he seemed to be OK with us looking at what parts would be a good fit for apr-util. He indicated that the project was looking to try and alter their code in various ways and so having more of their generic lib code available directly in apr-util may be a win for them as well. I'm not giving specifics yet as I'd like to know if people think we should do it, and then what pieces we should look at moving. The overhead of moving will be minimal and the changes required look to be also minimal. As a casual list reader who uses/distributes libapreq with his own project: http://biostat.mc.vanderbilt.edu/RApacheProject I welcome any collaboration that could further the idea of distributing libapreq with apache httpd (just as apr and apr-util are distributed with httpd) or even melding libapreq into apr-util. -- Jeffrey Horner Computer Systems Analyst School of Medicine 615-322-8606 Department of Biostatistics Vanderbilt University
R/Apache Integration Project
Hello allo, I'd like to point you to my project, mod_R: The R/Apache Integration Project which depends on libapreq2: http://biostat.mc.vanderbilt.edu/twiki/bin/view/Main/ApacheRproject With the mod_R 0.1.0 distribution, which is licensed under Apache 2.0, I've bundled libapreq 2.0.4. The install has the option of either installing the bundled version or linking to another version already installed. Comments, criticisms welcome. Thanks go to Joe Schaefer for his help spool files and bundling. -- Jeffrey Horner Computer Systems Analyst School of Medicine 615-322-8606 Department of Biostatistics Vanderbilt University
Re: Generated spool file okay to copy after parse?
Joe Schaefer wrote: [...] Maybe :-). The internal behavior of the spool brigades is something we need to work on from the httpd-side, since they have slightly different needs. I want to see our spool buckets become a bit smarter: right now mod_apreq2 is creating multiple spool files when it could (in principle) consolidate them into a single file. The safest thing for you to do right now is to write copy the brigade to a separate file. You shouldn't peek inside the brigade to look at the bucket types yet; ideally we'll provide another utility function to intelligently write the spool brigade to a file (here's my +1 for a patch to apreq_util.[ch] that adds an apreq_brigade_copy_to_file function). I'm not sure I like the idea of spooling the files to a tmp file just to copy them to another tmp file, which will ultimately be copied to another file by the script writer. Imagine this cost with a 500Mb file. My next idea is to create a hook to siphon off all the brigades for file params and write to the tmp files myself. This way, I'm using the libapreq api and not presuming what the internals do... How's that sound? -- Jeffrey Horner Computer Systems Analyst School of Medicine 615-322-8606 Department of Biostatistics Vanderbilt University
Re: Generated spool file okay to copy after parse?
Joe Schaefer wrote: [...] Certainly doable, but I think it'd be overkill. We deal with these exact same issues (by cheating and peeking at the spool bucket implementation) in the perl glue, so having a common C API makes the most sense to me. I don't claim expertise at understanding the Perl glue, but you might have a bug on your hands for the Apache2::Params::upload_link() function. If the brigade limit was set during parsing such that a file upload brigade contained heap buckets and a spool bucket at the end, then upload_link() looks like it may just copy the spool bucket, ignoring the heap buckets. Regardless, since libapreq already exposes the spool bucket file via the api call apreq_brigade_spoolfile(), plus the fact the the Perl glue uses it, I think it's a safe bet that the api will support some sort of access to the tmp file created in the future. -- Jeffrey Horner Computer Systems Analyst School of Medicine 615-322-8606 Department of Biostatistics Vanderbilt University
