On Apr 25, 2007, at 11:52 AM, Michael Peters wrote:
Boysenberry Payne wrote:
One of the draw back that seems to be evident to me as I've looked
into the client side frameworks is changes in the code are ought
of your control. WIth a purely server side solution it would seem
to give the coder t
On 25-Apr-07, at 8:55 AM, Justin Luster wrote:
Hi,
Recently I’ve noticed intermittent problems in the behavior of my
code when running under Mod_Perl 2.0. This particular code has
been out there for years with no problems. Recently I’ve seen a few
problems and I’m wondering if it has an
On 25-Apr-07, at 2:18 PM, Joshua Hoblitt wrote:
Doh! That indeed is the problem. A doc patch for Apache-Test 1.29 is
attached. ;)
Checked in as revision 532570.
Thanks for the patch!
Philippe M. Chiasson GPG: F9BFE0
On Apr 10, 2007, at 14:34, Jonathan Vanasco wrote:
Net::Amazon::S3 looks like it shouldn't have any memory /
management issues under mp2. just want to be safe.
It doesn't support using a filehandle for reading/writing the value,
so if you have very large files it will use a lot of memory
WOOT!
-- Forwarded message --
Date: Wed, 25 Apr 2007 18:46:51 GMT
From: Erwin Lansing <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: ports/111844: UPDATE: www/mod_perl 1.29 -> 1.30 (CVE Security Fix)
Synopsis: UPDATE: www/mod_perl 1.2
Ok, point taken I'll give her a go and see what happens. Thanks
guys
-Original Message-
From: Carl Johnstone [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 25, 2007 5:44 PM
To: modperl@perl.apache.org
Subject: Re: Are RHEL 3.0 & mod_perl 2.0.x compatible?
Jonathan Vanasco wr
Jonathan Vanasco wrote:
second:
your issue seems to be that you're trying to run everything via
rpms , which is causing your dependency issue.
try compiling from source. if you use cpan to install modperl,
it'll download all of the perl dependancies for you.
You *may* be able to fin
Doh! That indeed is the problem. A doc patch for Apache-Test 1.29 is
attached. ;)
-J
--
On Mon, Apr 23, 2007 at 05:20:34PM -0700, Geoffrey Young wrote:
>
>
> Joshua Hoblitt wrote:
> > Hi Folks,
> >
> > I just discovered that version of Apache::TestMB (no version string)
> > from Apache-Test
On Apr 25, 2007, at 3:21 PM, Michael Peters wrote:
Clinton Gormley wrote:
code, it's own CSS , it's own images! There should be a well
established usage pattern so someone just downloads the grid module,
run the installer and it puts all the files in 'right' places.
Of course, it's not possibl
Oh, heh heh, good point I should have mentioned that I'm way back
in the Clinton/Gore software era because we still have customers on RHEL
3. The difference is the jump to apache2/mod_perl2 from 1.3/1, that
I've been tasked with. Off to a great start...heh. I was hoping to get
some good adv
On Apr 25, 2007, at 4:48 PM, Dylan Tynan wrote:
Hi folks,
Been a few years since I've worked on mod_perl & I could use a
helping hand. Does anyone know if RHEL 3.0 and mod_perl 2.0.x
(like 2.0.2) are more or less compatible? RHEL 3.0 ships with that
semi-mutant 1.99 development track m
On Apr 25, 2007, at 8:13 AM, Carl Johnstone wrote:
RHEL5 comes with mod_perl 2.0.2, perl 5.8.8 and apache 2.2.3 so
it's *nearly* up to date!
=item 2.0.3 November 28, 2006
=item 2.0.2 - October 20, 2005
considering that its April 2007, i think using 2.03 and compiling
from source is the b
Hi folks,
Been a few years since I've worked on mod_perl & I could use a helping
hand. Does anyone know if RHEL 3.0 and mod_perl 2.0.x (like 2.0.2) are
more or less compatible? RHEL 3.0 ships with that semi-mutant 1.99
development track mod_perl I tried upgrading (on an x86_64
arch)
From: Praveen Ray
The bigger issue is not of client or server side controls. What's sorely
missing is a recommended best practice pattern that mod-perl people should
follow to package and deliver chunks of functionality.
"There is more than one way to do it" is an advantage, not a disadvantag
Clinton Gormley wrote:
>> code, it's own CSS , it's own images! There should be a well
>> established usage pattern so someone just downloads the grid module,
>> run the installer and it puts all the files in 'right' places.
>> Of course, it's not possible currently since everyone has a different
> code, it's own CSS , it's own images! There should be a well
> established usage pattern so someone just downloads the grid module,
> run the installer and it puts all the files in 'right' places.
> Of course, it's not possible currently since everyone has a different
> framework and different
The bigger issue is not of client or server side controls. What's sorely
missing is a recommended best practice pattern that mod-perl people should
follow to package and deliver chunks of functionality. I'm sure everyone here
has his/her own little framework of serving javascript, css, and html.
Boysenberry Payne wrote:
> One of the draw back that seems to be evident to me as I've looked
> into the client side frameworks is changes in the code are ought
> of your control. WIth a purely server side solution it would seem
> to give the coder the choice to upgrade when there is time, etc.
>
One of the draw back that seems to be evident to me as I've looked
into the client side frameworks is changes in the code are ought
of your control. WIth a purely server side solution it would seem
to give the coder the choice to upgrade when there is time, etc.
With the 3rd party frameworks they
Hi,
Recently I've noticed intermittent problems in the behavior of my code
when running under Mod_Perl 2.0. This particular code has been out
there for years with no problems. Recently I've seen a few problems and
I'm wondering if it has anything to do with Mod_Perl 2.0, it has been
running fin
Just a follow up to my previous announcement.
The TinyMCE perl compressor now has a permanent home:
http://hacks.traveljury.com/perl_compressor
any bugs to me: [EMAIL PROTECTED]
About
TinyMCE Compressor gzips all javascript files in TinyMCE to a single
streamable file. This makes the overall do
RHEL5 is out and from memory it has a proper version of MP2 (somebody like
to confirm whether you can just upgrade from 4 to 5?)
To answer my own question - yes you can upgrade:
http://www.redhat.com/rhel/moving/
although I don't know what the process is.
RHEL5 comes with mod_perl 2.0.2, perl
On 25 Apr 2007 at 12:18, Carl Johnstone wrote:
> > I tried to the package manager to install mod_perl and it offers me
> > mod_perl-1.99-16.4
> >
> > I thought that Apache 2 required MP2. Am I mistaken? I am not sure
> > what the best route to take is, even my httpd server version is a bit
> > old
I tried to the package manager to install mod_perl and it offers me
mod_perl-1.99-16.4
I thought that Apache 2 required MP2. Am I mistaken? I am not sure
what the best route to take is, even my httpd server version is a bit
old. Do I throw out the httpd server and start from scratch, possibly
con
On Wednesday 25 April 2007 12:25, Beginner wrote:
> I was expecting Server: Apache/2.0.52 (Red Hat) mod_perl (some
> version number)
>
> I tried to the package manager to install mod_perl and it offers me
> mod_perl-1.99-16.4
Both are quite old. Especially the mod_perl version is BETA and offers a
Hi,
I have been in this situation before but want to clarify something.
I have a vanilla RH4 install and wanted to check that mod_perl was
installed. So I did a test on port 80 ala:
telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
There is a consideration, regarding using a proxy or a different server,
that has not been brought up: If there is mod_perl based access control
for the static files, then it's basically impossible not to go through a
mod_perl server to serve them.
If you're access control is in mod_perl, you ha
ASP.Net tries to do both the server and client side (sometimes the programmer
doesn't even know if his C# code is actually going to be run on the server or
the client). Perl (and on this list mod_perl) takes care of the server side but
leaves the client side up to you.
I believe that's the gr
28 matches
Mail list logo
