Would that necesarily be the case?
If mod_dbd is just providing the connection pooling, would it be
possible to write a mod_perl2 adapter/subclass/driver to let DBI pull
it's connections out of that pool?
Adam K
Perrin Harkins wrote:
On Fri, 2005-12-02 at 19:34 +0100, Tom Schindl wrote:
j
Indeed.
All that might be needed is a small...
=head1 COMPATIBILITY
Apache::DBI is compatible with both the mod_perl 1 and mod_perl 2 APIs.
... somewhere very near the beginning of the POD. (personally I'd have
it right after the synopsis and before the description).
And I'd recommend this
...
offer bounties
"i will code one task of your choice for as many hours as you
code on a task of my choice"
voila, no money involved and still a hook
But I don't need these idea implemented
If I did, I'd do them myself
yeah.
* CPAN upload: mod_perl-2.0.0 by GOZER
whoah
whoa!
* Alias chan
Eeep... I missed it entirely. :)
Adam K
Philip M. Gollucci wrote:
Adam Kennedy wrote:
It sounds like the appropriate time for some enterprising young
developer to grab a copy of PPI and write an mp2_rename tool, to do a
first pass of what you describe below automatically.
http
It sounds like the appropriate time for some enterprising young
developer to grab a copy of PPI and write an mp2_rename tool, to do a
first pass of what you describe below automatically.
Anyone?
Adam K
Geoffrey Young wrote:
it sucks, completely. i can't get my stuff to work under rc5
I feel f
I don't know the full story, but I am pretty sure that the movers and
shakers in the decision team have a strong point for it (possibly
documented in perl.apache.org). It's caused me unexpected pain recently
as well; and I have to spend today as well working through my codes
because of it. But
Michael J Schout wrote:
Hey everyone.
I am working on updating Apache::AuthCookie to work with mod_perl
2.0.0-RC5. In past releases, both the MP1 and MP2 versions of
AuthCookie were installed as Apache::AuthCookie, even though the MP2
version of the module has several API changes in order to b
For the record, and those that haven't seen CGI::Capture before (I wrote
it only fairly recently) all it really does is grab the environment and
a couple of magic variable values, then take STDIN before CGI.pm gets a
chance to parse it.
These bits are all stored in an object, which is just Stor
hmmm... prefork.pm was created for this sort of problem, when some form
of run-time loader is being silly, and everything should really just be
loaded in at compile-time.
I wonder if it's time to investigating adding autoloader support to
prefork.pm some how.
For anyone else that has issues at
of mod_perl.
Once the PMC has made an informed decision, there will of course be no
point to continuing the discussion, and I plan to get back to my current
projects and limit myself to more positive activities.
Regards
Adam Kennedy
John Siracusa wrote:
On 12/31/04 4:40 PM, Stas Bekman wrote:
Finally you don't want to use it - don't use it. It's an open source
software, it will succeed or fail by *its own merits* and not because the
infrastructure has a long known problem but is not willing to evolve.
And to repeat this again.
re I begin, since this is a much wider
audience, a quick introduction.
For anyone that doesn't know me, my name is Adam Kennedy. I'm the author
of 56 CPAN packages, including several that deal with strange module
loading situations, the open source tool CVS Monitor, I have a small
compa
12 matches
Mail list logo
