Re: mod_perl & mod_php

[Iain Truskett]

* Jie Gao ([EMAIL PROTECTED]) [30 Aug 2002 09:49]:
> On Thu, 29 Aug 2002, Jesse Erlbaum wrote:
[...]
> > I notice that you are using mod_perl AND mod_php.
> >
> > I have a general question for the list: Do people often use BOTH of
> > these environments at the same time? It seems to me that there would
> > be little benefit to using both. Am I mistaken?

> It happens when somebody wants to use php and you don't want to use
> it.

We had both for a while --- then I got fed up and rewrote the small
amount of PHP into Mason. I've been happier ever since =)


cheers,
-- 
Iain.

Re: mod_perl & mod_php

[Iain Truskett]

* Andy Lester ([EMAIL PROTECTED]) [30 Aug 2002 10:33]:

[...]
> PHP is better than Perl in some cases, I've found. If you're
> predominantly templating and don't want to futz around with Mason or
> TT or whatever, PHP will do a fine job.

I'm naturally biased toward Perl, and generally the PHP I've seen sucks
(written by a non-programmer futzing around with third-hand code).

Is there good PHP code out there?

(I don't want to get into a war over PHP vs Perl, so please don't start
one.)


cheers,
-- 
Iain.

Re: Change in module naming conventions

[Iain Truskett]

* Stas Bekman ([EMAIL PROTECTED]) [28 Aug 2002 12:54]:
> Nick Tonkin wrote:

[...]
> > I'm in favor of your approach. I have it like that in my stuff.
> > Auth::Auth, Auth::Authz, and Auth:: Access.

> But Authentication, Authorization and Access aren't all Auth. May be
> using Apache::AAA:: as in httpd-2.0/modules/aaa/ ?

I'd have to favour them being in a second-level namespace rather than a
top-level one. If they provide Apache related handlers, the Apache
handler modules should be in Apache:: (or ModPerl::, Apache2::
whatever; I'm going to have to look up the new naming convention there).

Generic authentication stuff should probably belong in the namespace of
the appropriate protocol. (e.g. Net::LDAP::Authenticate, used by
Apache::AAA::NetLDAP).

But Apache specific stuff should be in an Apache related namespace.

(of course, now you'll all say that the 'toplevel' thing mentioned
previously was relative to Apache::. Hrm.)

cheers,
-- 
Iain.

Re: Hiding perl code

[Iain Truskett]

* Jonathon M. Robison ([EMAIL PROTECTED]) [22 Jul 2002 13:03]:
> Anyone know offhand a good way to hide your perl code when using
> mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on
> initial test [...]

Acme::Bleach is a source filter. Source filters will just screw up your
mod_perl stuff. IIRC, you get similar problems using Switch and so on.

> Perhaps perl2exe?

Nope. That does weird compiler stuff that will interfere with the fact
that Apache's using Perl internally.


As far as I know, there's no good way to do it. It is Perl after all.
And with mod_perl things just get trickier.

Out of interest, why?


cheers,
-- 
Iain.

Re: the cookbook review on perl.com

[Iain Truskett]

* Jon Robison ([EMAIL PROTECTED]) [27 Apr 2002 00:12]:
> Hmmat least I have the excuse that I'm not a writer ;-)

That's fine. Simon's not a copy editor. =)


cheers,
-- 
iain.  

Re: [WOT] Google Programming Contest.

[iain truskett]

* Randal L. Schwartz ([EMAIL PROTECTED]) [08 Feb 2002 05:28]:
> * "Dave" == Dave Rolsky <[EMAIL PROTECTED]> writes:
> > In the Slashdot discussion, there's a link to a usenet posting by a
> > Google employee which explicitly says only C++ or Java, no Perl or
> > Lisp.

> "A google employee" is perhaps only an opinion though. Is it the group
> running the contest?

Yes, it's an official opinion.


cheers,
-- 
iain.  

Re: [OT] RE: New mod_perl Logo

[iain truskett]

* Rob Bloodgood ([EMAIL PROTECTED]) [31 Jan 2002 09:32]:
> Uhh... the platypus, the wombat, the tazmanian devil, and the emu.

That's 'Tasmanian'. And they're wonderfully cute and vicious brutes.


cheers,
-- 
iain.  

Re: Fast template system

[iain truskett]

* Ryan Thompson ([EMAIL PROTECTED]) [31 Dec 2001 08:19]:

[...]
> I've tried or at least taken a critical look at most of the template
> systems out there, and they [...] use constructs/syntax that break
> HTML validation.

Surely you only validate your HTML that's served and not your template
system source?

I, personally, would be quite annoyed if I had to do things like:


blah blah

flarp flarp



cheers,
-- 
iain.  

Re: embperl

[iain truskett]

* Medi Montaseri ([EMAIL PROTECTED]) [08 Sep 2001 22:58]:

> Another advantage of Perl is that you can use this language in other
> situations as well. Unlike PHP, or ColdFusion or other languages who
> need something to tow them.
[...]

Much as I hate to give PHP a pro rather than a con, I must point out
that PHP can be used independently from a web service. It can be happily
used as a general purpose scripting language.

Of course, you don't get CPAN...


cheers,
-- 
iain.  

 PGP signature

Re: embperl

[iain truskett]

* Jim Cox ([EMAIL PROTECTED]) [07 Sep 2001 08:03]:

> This will sould like sour grapes,. But!

> Since PHP module compiles,... and Mod_Perl will not on AIX with gcc
> compiler

> I'm thinkin' PHP is getting better and better all the time.

It's all a case of "use what works" =)

There's something peculiar with one of my Apaches in that it refuses to
use DSOs. And I've got mod_perl happily compiled into it.

On my home site, the admin of the machine has PHP installed but not
mod_perl.

At work, I haven't been able to convince the sysadmin to install either.
And if I do, he's more likely to go for PHP since it's less likely to
require many configuration changes. mod_perl can attach modules to any
part of a request/response phase and thus can be configured somewhat
complexly.

PHP is just a content handler, right?

mod_perl is an everything handler: content, headers, logging, URI
translation, etc. etc. It's more powerful. As far as I know, there's
nothing PHP can do that mod_perl can't.

Well, apart from compile on AIX with gcc =)


cheers,
-- 
iain.  

Re: embperl

[iain truskett]

* Diego V ([EMAIL PROTECTED]) [07 Sep 2001 06:59]:

[...]
> Just wanted to ask to any embperl user, is there any real advantage
> about using embperl instead of PHP ?

You get the advantage of using Perl rather than PHP.

This includes the vast resources of CPAN.

Personally, I recommend Mason  over Embperl
simply because I prefer the way it integrates into HTML.

Investigate both =)

I've done reasonably sized projects with both and find Mason cleaner
(mostly in its handling of scope and the way it doesn't use all those [-
[+ [# [$ [* etc. tags and instead just has <%, <%init and other wordy
ones: easier to remember =). )


cheers,
-- 
iain.  
"The only disadvantage I see is that it would force everyone to get
 Perl. Horrors. :-)" --Larry Wall in <[EMAIL PROTECTED]>

Re: ssl advice? modssl vs. apache-ssl vs. ?

[iain truskett]

* Michael Robinton ([EMAIL PROTECTED]) [14 Apr 2001 17:23]:
> > I've just taken a quick look at the modssl site and the apache-ssl
> > site. Does anyone want to comment on the pros and cons of these 2
> > approaches?
> >
> > Can mod_perl co-exist with either or both of these?
[...]
> Don't know anything about modssl, I've been using apache-ssl +
> mod_perl for several years and am quite happy with the results.

Apache/1.3.19 (Unix) PHP/4.0.4pl1 mod_perl/1.25 mod_ssl/2.8.1 OpenSSL/0.9.6

Been happily working with various versions for the past year on the
above machine and another one. mod_perl happily coexists with mod_ssl.

Simple to install, simple to use.


cheers,
-- 
iain.  
Be nice to your kids They will pick out your nursing home.

Re: Delving into Apache's configuration innards

[iain truskett]

* Stas Bekman ([EMAIL PROTECTED]) [08 Mar 2001 02:36]:
> On Thu, 8 Mar 2001, iain truskett wrote:
[...]
> > > http://perl.apache.org/guide/config.html#Verifying
> >
> > Except that (a) adding $Apache::Server::SaveConfig = 1; to my 
> > bit has the side effect of stopping the virtualhost hash being
> > filled out properly, and

> You may want to submit a bug report providing all the details. Just
> sayind "improperly filled out" doesn't tell much.

I was going to once I figured out exactly what it was doing. Weekend job
that.

> > (b) according to the documentation you pointed out (which I had
> > checked previously) it doesn't give me access to the entirety of
> > the configuration, only what I set in the  sections.

> The documentation mentions this fact, I believe.

"according to the documentation you pointed out"...

[...]
> Use mod_info: http://httpd.apache.org/docs/mod/mod_info.html But it's
> not aware of the C sections. I suppose that Apache::Status can
> be improved to merge the info from mod_info and the C sections,
> so if anybody wants to do that you are very welcome.

Sounds like a plan. I'll see what I can get done with mod_info.


cheers,
-- 
iain.      <http://eh.org/~koschei/>
  "I'd just like to take this opportunity to say: Iain Truskett, you
  are a crafty git!" -- Erik Pollitt, The Jade Pagoda, 2208.

Re: Delving into Apache's configuration innards

[iain truskett]

* Stas Bekman ([EMAIL PROTECTED]) [08 Mar 2001 01:48]:
> On Wed, 7 Mar 2001, iain truskett wrote:
[...]
> > I'd like to be able to display all of my web server's configuration
> > on a web page. Since a fair amount of it is automatically generated
> > I was wondering if there was a way to easily obtain a dump (of hash
> > and array references) to munge and display on the page.

> http://perl.apache.org/guide/config.html#Verifying

Except that (a) adding $Apache::Server::SaveConfig = 1; to my  bit
has the side effect of stopping the virtualhost hash being filled out
properly, and (b) according to the documentation you pointed out (which
I had checked previously) it doesn't give me access to the entirety of
the configuration, only what I set in the  sections.

Mind you, I could go and translate the rest of the configuration into a
 section so that the whole thing is a perl program but I'd rather
not unless I have to.

Thanks anyway.

cheers,
-- 
#!/usr/bin/perl -- # -- iain.  <http://eh.org/~koschei/>
($#=q/M2VYO=VQE9,=E($%B;W9E($%L;"X*.,AT='`Z+R]E:"YOF4^"|``/)=~y-,.|\r\n\t -&/@-d,$;=pack c,280551%015025;print unpack$;,$#

Delving into Apache's configuration innards

[iain truskett]

Hello,

I'd like to be able to display all of my web server's configuration on a
web page. Since a fair amount of it is automatically generated I was
wondering if there was a way to easily obtain a dump (of hash and array
references) to munge and display on the page.


cheers,
-- 
iain.  
51 things to do in a lift
 18. When at least 8 people have boarded, moan from the back: "Oh, not
 now, damn motion sickness!"

Re: PerlRequire conf/startup.pl

[iain truskett]

* Dennis ([EMAIL PROTECTED]) [14 Oct 2000 16:00]:

> I have "PerlRequire conf/startup.pl" in httpd.conf
> and startup.pl has  "1;" in it
> then I start apache "/usr/local/apache/bin/apachectl start

> and it says:
> /usr/local/apache/bin/apachectl start: httpd started

> but it looks like it's exiting out right away.  is that what it's supposed to do ?

Do you mean httpd is exiting right away or that startup.pl is?

If the former, then have you looked in your Apache error log?

If the latter, then that's good since startup.pl is meant to be run at
the start of an httpd starting up and just set some things up for later
(I use it to get XML::Parser and stuff into memory early on to speed up
the first requests).


cheers,
-- 
iain truskett, aka Koschei.<http://eh.org/~koschei/>
You know you are addicted to coffee if...
 8  You chew on other people's fingernails.

XML::Parser 2.30

[iain truskett]

For what it's worth, the new verion of the XML::Parser module appears to
segfault.

Works fine outside mod_perl from what I can see, but segfaults the
Apache child within.

This is using it with XML::RSS on:

Apache/1.3.12 (Unix) PHP/3.0.16 mod_perl/1.24 mod_ssl/2.6.2 OpenSSL/0.9.5a

Linux dijkstra 2.2.12-20 #1 Wed Apr 12 15:43:14 EST 2000 i686 unknown


Downgrading to 2.29 fixed the problem.


cheers,
-- 
iain truskett, aka Koschei.<http://eh.org/~koschei/>
  The book to read is not the one which thinks for you, but the one
  which makes you think.  ---James McCosh