from:"\"Per Einar\""

Hi Joerg,

At 18:06 16.10.2002, Joerg Plate wrote:
>although it never happened to me i have to fight some rumours. Is
>it true that you can kill the whole server, not just the script
>if you do something wrong with mod_perl? (I doubt it)

It depends on what "wrong thing" you do. mod_perl gives a great deal of 
freedom, and with freedom comes responsibility. Things like using a lot of 
memory and the fact that mod_perl scripts/modules can access each others 
namespaces can make for some problems. You probably want to look at : 
http://perl.apache.org/docs/general/multiuser/multiuser.html

But just throwing an error (because of some unexpected condition, for 
example), won't kill the whole server.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Can I parse content that has been returned to user by simple cgi script?

At 16:47 16.10.2002, Ruslan U. Zakirov wrote:
> >>I want to upgrade my project with implementing some feature.
> >>Project was writen for mod_cgi, but I would like to parse content that
> >>was generated by my scripts to implement something like SSI or
> >>Apache::UCase and etc.
>
>PH> You can't do that.  However, you can run your CGI scripts under
>PH> Apache::PerlRun and then use Apache::Filter on them to do things like
>PH> SSI.  This will also make them much faster.
>PH> - Perrin
>Thank you!
>Now I've uderstood that it's only way.
>OK.
>And last one, could someone point me to documents about troubleshoots
>which could ocure while using Apache::PerlRun with CGI scripts that was
>writen only for mod_cgi?

There aren't many problems with Apache::PerlRun, as it goes to great 
lengths to be a direct equivalent to mod_cgi so that "dirty scripts" can run.
Anyway, the Guide is always here to help. See especially 
http://perl.apache.org/docs/1.0/guide/porting.html , although a lot of this 
is for Apache::Registry, which you might want to move on to later.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: mod_perl Guide Patch


Hello Lee,
>So, I simply meant that if you are trying to get $|=1 type "instant" output
>and your HTML header pulls in other files -- using
>
> 
>
>or
>
> 
>
>then you will not get the expected output instantly, but only after the
>whole document has loaded.
>
>I guess this is because the document will not be rendered until
>the browser (or let's face, the IE6) has received the external files
>and the whole BODY.
>
>If you trying sticking a CSS/script link in the $q->html_head call
>in the mod_perl Guide example, you should see what I mean.

Sure, I understand what you mean now. I'll consider it for inclusion. Thank 
you for your contribution.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: posts headers and so on.


Hello Innerlab,

At 15:18 16.10.2002, Innerlab wrote:
>Hello:
>
>I just subscribed to the list. I don't want to be a pain in the ass
>so soon, but I've  noticed that (at least on yahoo),
>these posts cannot be automatically replied to the list.
>They go by default to whoever wrote the original email, thus one has
>to manually replace that address for "[EMAIL PROTECTED]" .

This is intentional. You have to use "Reply to all".

>Also, neither the "Subject", the "To:" or the "From:" information in
>the header doesn't mention "modperl * " , making it hard to filter
>these emails.

Use a filter that checks To: and Cc: for the presence of 
[EMAIL PROTECTED] (which is btw the correct address), and filter 
based on that.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

mod_perl history

2002-10-15 Thread Per Einar Ellefsen


Hello mod_perlers,

I have been working on a document retracing mod_perl's history for a while. 
While it's not finished yet, I have decided to put it online so that you 
can all have a look at it and contribute additions which are sorely needed. 
It currently only deals with mod_perl 1.x, as well as related events.

You can find it at: http://perl.apache.org/about/history.html

If you have something to contribute, please send it to me directly or to 
the docs-dev list. Everything in relation to mod_perl, Perl or Apache is 
welcome, such as the appearance of important modules, new major releases of 
Perl or Apache, or the items listed in the "META" list, to name a few 
examples. As well as 2.0 information, of course.

Your faithful historian,

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: mod_perl Guide Patch

2002-10-15 Thread Per Einar Ellefsen


At 13:07 25.10.2002, Lee Goddard wrote:
>Well, not really a patch but a tiny contribution to an
>excellent guide -- Mr Beckman, I hope this is of use:
>
>On/section:
>
> guide/performance.html#Using_1_Under_mod_perl_and_be
>
> "Using $|=1 Under mod_perl and Better print() Techniques"
>
>Whilst the code is correct, even if it does use CGI.pm...,
>It might be a good idea to mention that if an external file is pulled
>in by the header, it seems that it has to be loaded before any
>output occurs.
>
>My print_html_header methods have a flag which will cause
>SCRIPT src  and relevant LINK href URIs to be parsed,
>loaded and included inline. Slow but better than a poke in the eye
>with a sharp stick.

Hello Lee,

I'm sorry, but I'm not sure I understand what you mean by "an external file 
is pulled in by the header". I understand your example, but not its 
relation to the section you refer to. Could you give a code example or some 
more information?


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Does Apache::NavBar exist ?

2002-10-14 Thread Per Einar Ellefsen


At 12:01 14.10.2002, [EMAIL PROTECTED] wrote:

>Hi
>
>I've just been perusing the docs on perl.apache.com and in the "Cute Tricks"
>section there is mention of a module called Apache::NavBar being available 
>from
>CPAN. I may be blind but I can't find it. Does it exist ?

Hi Paul,

Weird, it doesn't show up on search.cpan.org, but it seems to be on CPAN 
still: http://www.cpan.org/authors/id/B/BA/BARRACODE/
Otherwise you can find a copy here: 
http://modperl.com:9000/book/source/apachemod-code-1.02/lib/Apache/


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

[ANNOUNCE] New naming conventions for modules

2002-10-08 Thread Per Einar Ellefsen


Hello mod_perlers,

Following talk about module categorization this summer, I have now finally 
added these recommendations to the website.

The new naming conventions for modules in the Apache:: namespace are 
summarized here: http://perl.apache.org/products/apache-modules.html

In my work to define new namespaces, I also undertook a categorization of 
the current mod_perl modules into new namespaces. This can be useful for 
module authors to know what name to pick for their new modules, as well as 
for users that are looking for a module but have trouble finding it because 
of poor organization of the Apache:: namespace.

You can find this categorization here: 
http://perl.apache.org/products/old-modules-categorized.html . I remind you 
that it is only of illsutrative interest, and *is not a proposal to change 
the names of established modules*.

However, I suggest that we all work together to help new modules (1.0 as 
well as 2.0) choose a correct namespace in the Apache:: main namespace.

I hope that this suits everyone. Of course, it is flexible: nothing is 
settled and as everything, I am sure it is going to evolve. But it's a step 
forward, which everyone seemed to agree was important.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: different versions of one .pm in mod_perl

2002-10-07 Thread Per Einar Ellefsen

At 12:09 07.10.2002, Plamen Stojanov wrote:
>I have installed apache 1.3.26 and mod_perl 1.27. I have two virtual servers
>setuped in apache server. Is there any easy way to use two versions of
>one .pm - first version in first virtual host, and second version in second
>virtual host. Using these versions of .pm is done under mod_perl environment.
>I don't want to modify the name of .pm or the way it is called.

This is a classical problem in mod_perl, and its solution is intricate. I 
suggest that you read the following:
http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Apache::Constants in startup.pl

2002-10-06 Thread Per Einar Ellefsen


At 21:29 06.10.2002, allan wrote:
>hi per
>
>thanks very much for the reply.
>
>hmm, ok then. i see. so another theoretic workaround [though ugly]
>could be to use the fully qualified name of the constant, like
>
>   return Apache::Constants->OK if $r->header_only;

Yes, but it would be Apache::Constants::OK instead.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Apache::Constants in startup.pl

2002-10-06 Thread Per Einar Ellefsen

At 17:42 06.10.2002, allan wrote:
>   use Apache::Constants ':common';
>
>to my startup.pl file.
>
>but if i do that switch, i will get this kind of error:
>
>[error] Bareword "OK" not allowed while "strict subs" in use
>
>
>why is that ?

Hi Allan,

This is because when you issue use Apache::Constants ':common'; the 
constants are loaded into the namespace calling this use statement.
However, when you get to your handler, you're in a different namespace from 
your startup.pl file; consequently, the bareword 'OK' isn't defined.

In mod_perl 2, the constants are loaded into the Apache:: namespace 
instead, so your trick would work.

But does it really cost you that much to have that small line at the top of 
your handler code? There are worse things :)

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Graphics and mod_perl

At 01:41 03.10.2002, Justin Luster wrote:

>
>
>I m new to mod_perl and I m really enjoying it.  It has really improved 
>performance.  Right now I m just using Modperl::Registry to speed up 
>things.  I have a question about showing graphics using a Perl Script and 
>running it through mod_perl.
>
>
>
>Using Perl under regular CGI to create a dynamic web page I have always used:
>
>
>
>print  ;
>
>
>
>and this would display the graphic to the web page assuming that the file 
>thefile.jpg  was in the same directory as the Perl script .  If the 
>graphic was in another directory then something like:
>
>
>
>print  ;
>
>[...]
>
>print http://www.mysite.com/graphics/thefile.jpg\ > ;
>
>but it seems that there is a delay in displaying the graphic when I do this.
>
>Where is the current working directory when running a Perl script under 
>mod_perl.

Hello Justin,

You seem to misunderstand the working of the HTML  tag. All you're 
doing is to give an idea to the *browser* about where it should find the 
image, relatively to the *URI* of your script.
Simply put, before you had:
/cgi-bin/yourscript.cgi ---> img src="thefile.jpg" ---> browser tries to 
fetch /cgi-bin/thefile.jpg
Now, you have:
/ssiweb/yourscript.pl > img src="../graphics/thefile.jpg" ---> browser 
fetches /ssiweb/../graphics/thefile.jpg = /graphics/thefile.jpg

You have almost found the best solution when in doubt: using absolute URIs.
However, as you noticed, using the full URL is slower because the browser 
has to check the DNS again etc etc.
So, if your graphics are acccessible as 
http://www.example.com/graphics/file.jpg, then you can insert an img tag 
with src="/graphics/file.jpg". Note the first slash which says to the 
browser "Begin at the root of this site and fetch the following URI".

Ok?

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: passing an object to a handler

At 21:30 02.10.2002, william ross wrote:

>On Wednesday, October 2, 2002, at 08:18 PM, Per Einar Ellefsen wrote:
>
>>At 20:47 02.10.2002, william ross wrote:
>>>but I can't find anything to tell me how to do it. I feel sure I'm 
>>>missing something really obvious here?
>>
>>You can configure objects instead of using static class names. See the doc:
>>
>>http://perl.apache.org/docs/1.0/guide/method_handlers.html
>
>sorry: i wasn't very clear, was I? I am using a method handler, but I want 
>to pass an object of another class to it each time it is called. The 
>object needs to be created outside of an individual request, and therefore 
>presumably in a startup file, and then either passed to the handler along 
>with each request, or somehow made available to all the requests, but 
>preferably without setting a class variable, which is what I do at the 
>moment but dislike.

Yes, and that it exactly what the doc I referred to shows you:
You instantiate an object in your startup file; then you configure mod_perl 
to call your handler with this object as the class, like:
PerlHandler $My::obj->handler
$My::Obj must then be an instance of the handler class, but can contain any 
other information too.
Now, in your handler, you get:
sub handler ($$) {
my ($obj, $r) = @_;

and you have your $obj, which you can use freely. ($obj isn't a class name, 
it is an ... object!)

Wasn't that what you wanted?

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: passing an object to a handler


At 20:47 02.10.2002, william ross wrote:
>hello,
>
>I've been off-list for a while, so please forgive (and direct) me if this 
>is a tired subject.
>
>In short, i'd like to pass through another object on method invocation, in 
>addition to the apache request. Ideally the (method)handler would look 
>something like:
>
>sub handler ($$$) {
> my ($class, $r, $factory) = @_;
> ...
>}
>
>where $factory is an object I made earlier, and is shared among all the 
>requests. I'd like to avoid class data because the handler will almost 
>always be subclassed, and anyway it makes me nervous. And for the same 
>reason I don't want to make the factory a singleton: each single, 
>hard-working object of the factory class will have a different configuration.
>
>but I can't find anything to tell me how to do it. I feel sure I'm missing 
>something really obvious here?

You can configure objects instead of using static class names. See the doc:

http://perl.apache.org/docs/1.0/guide/method_handlers.html


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: cookies and IE

At 20:12 02.10.2002, Alan wrote:
>On Wed, Oct 02, 2002 at 01:21:49PM -0400, Geoffrey Young wrote:
> > so, it's not really a bug if you dig down into the docs and examples.
> >  looks like a feature, though :)
>
>Agreed... more of a 'gotcha' though, ready to bite people in the butt.
>Personally I think it might make more sense to do a check to see if the
>val =~ /(\d+)(h|m|d|M)/ before it's sent off as a literal, but who
>knows.  I'll email someone about it anyway.

It's because you can put a correctly formatted date string in the -expires 
option, AFAIK. So if using your idea, the "literal" string might be 
misinterpreted. Also, don't forget that you have +1d and -1d as another 
possibility. I think the +/- makes sense. It's just one character :)

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: cookies and IE


At 09:02 02.10.2002, Alan wrote:
>On Tue, Oct 01, 2002 at 07:23:39PM -0400, Kee Hinckley wrote:
> > At 11:30 AM -0700 10/1/02, Alan wrote:
> > >Hi folks... I'm having a bit of a weird problem with Apache::Cookie and
> > >IE.
> > >
> > >I'm setting a cookie and then doing a redirect as follows:
> >
> > This must come up once every few months.  I'd complain about that
> > fact, but the irony is that just last week I couldn't figure out why
> > a new site I was working on wasn't setting cookies in IE and  I'd
> > done the same thing I'd read about a dozen times.
> >
> > IE doesn't reliably set cookies on a refresh.  I believe the only
> > solution is to rearchitect the site.
>
>Interesting... on the several browsers/OSs I had it tested on it seemed
>to work.
>
>Anyway, if this is such a common question, who do you talk to to get it
>stuck in the perl.apache.org page about cookies? :)

Send some paragraphs detailing this to me (preferably in POD), and it'll be 
added to the site.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: FW: ezmlm response

2002-09-12 Thread Per Einar Ellefsen


At 04:19 13.09.2002, Ask Bjoern Hansen wrote:
>On Thu, 12 Sep 2002 [EMAIL PROTECTED] wrote:
>
> > Hi,
> >
> > is there a way to subscribe to mod_perl digest only?
> > The page http://perl.apache.org/maillist/modperl.html
> > lists strangely the same address as for normal subscr.
>
>That's a typo then; it should be
>[EMAIL PROTECTED] to subscribe to the digest.

Thanks for the catch, corrected now.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: $r->push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork

2002-09-01 Thread Per Einar Ellefsen

At 21:05 01.09.2002, Rodney Broom wrote:
> > Apache will not run the Authen or Authz phases unless there is a
> > Require directive, no matter what you put onto the mod_perl handler stack.
>
>I sort of thought this myself, so I tried $r->dir_config->add('require', 
>'valid-user') in the access handler. No help.

dir_config is the Perl{Set,Add}Var configuration, and has nothing to do 
with Requires. Requires is set within httpd.conf like:
Require valid-user

You can just add that and let your handler decide regardless of the value 
of requires (which is accessed through $r->requires btw, see  the Eagle or 
the cookbook).

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Authentication Question

2002-08-28 Thread Per Einar Ellefsen

Please do not send replies directly to me, Cc the list.

At 13:40 28.08.2002, Brett Hales wrote:
>On Wed, 2002-08-28 at 17:47, Per Einar Ellefsen wrote:
> > At 09:55 28.08.2002, Brett Hales wrote:
> > >I have a mod_perl cgi script that I would like to get the username from
> > >the Apache server. The apache server successfully authenticates the
> > >client using Apache::AuthenSmb.
> > >
> > >How do I get this environment variable (the username) from apache into a
> > >variable in the perl script.
> >
> > It's $ENV{REMOTE_USER} or $r->user
>I have tried to use both of these,
>
>$login_name = $ENV{REMOTE_USER};
>
>and
>
>$login_name = $r->user;
>
>With the ENV I do not get anything when I print $login_name. With
>$r->user I get the following in the error_log.
>
>Cannot call method "user" without a package or object reference at
>..
>
>Do you have any advice, thanks again.

First of all: $r->user doesn't work because you haven't gotten the Apache 
request object. To get it in an Apache::Registry script, insert:
 my $r = Apache->request;
before your call to $r->user.

Why you aren't getting anything in $ENV{REMOTE_USER} I do not know. It 
might be that the environment isn't set up that way in Apache::Registry. Or 
maybe Apache::AuthenSmb doesn't set $r->user at all. Are you even nsure the 
authentication is working?

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Authentication Question

2002-08-28 Thread Per Einar Ellefsen


At 09:55 28.08.2002, Brett Hales wrote:
>I have a mod_perl cgi script that I would like to get the username from
>the Apache server. The apache server successfully authenticates the
>client using Apache::AuthenSmb.
>
>How do I get this environment variable (the username) from apache into a
>variable in the perl script.

It's $ENV{REMOTE_USER} or $r->user


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: SSI and mod_perl

At 23:09 27.08.2002, Jay Thorne wrote:
>In a mod_perl handler, in the m_p1.x/apache1.3 api, Is there a quick way to
>tell apache
>"I'm done, here's my content, and I want you to run this through mod_include
>before you send it to the user"

You might want to try a filter, for example Apache::OutputChain, see 
http://perl.apache.org/docs/1.0/guide/modules.html#Apache__OutputChainChain_Stacked_Perl_Handlers

and the Apache::OutputChain manpage formore information. The same is true 
for Apache::Filter: 
http://perl.apache.org/docs/1.0/guide/modules.html#Apache__Filter___Alter_the_output_of_previous_handlers

. Both provide approximately the same functionality.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Change in module naming conventions

At 20:14 27.08.2002, James G Smith wrote:
>Per Einar Ellefsen <[EMAIL PROTECTED]> wrote:
> >What I came to was this:
> >http://users.skynet.be/pereinar/mod-perl/modules.txt
>
>Looks good, overall.
>
>I like the Apache::Framework:: namespace :)

same; just shows how many there are.

> >Some questions I got which I'm not too sure of:
> >- I originally had Apache::Auth::Authen, ::Authz and ::Access, but Robin
> >Berjon told me he preferred to have the 4 as top-level namespaces. What do
> >people think?
>
>What's the difference between Apache::Auth and Apache::Authen ?  They
>both seem to have authentication handlers.

There are modules that do Authen+Authz,  and some that incorporate general 
functions related to authentication and authorization. These go into 
::Auth. The Authentication handlers go into Authen, as well as other 
modules *only* related to _authentication_.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Flaky behavior with modperl module

At 19:37 27.08.2002, The Surprises wrote:
>Greetings,
>
>I am writing a modperl module to create dynamic picture web pages
>created from .jpg files in a given directory.  It basically puts a bunch
>of pictures on the screen.  I am seeing inconsistent behavior and I
>don't know where to look for a solution.  When I load the page, random
>pictures don't get loaded.  They're just small boxes on the screen.
>Reloading the page will give me another set of random missing pictures.
>The server is behind a cable modem and it has a max upload bandwidth of
>256kb, so it's kinda slow.  Am I seeing some sort of timeout or
>flakiness with my cable modem bandwidth?

As you don't give a lot of information about your configuration, this is 
just a wild guess, but I suppose that your image files get corrupted 
somehow, maybe because the directory they reside in is configured to be 
served through CGI or Apache::Registry.

Can you fetch the images with a direct URL? Are you sure the URLs are even 
correct? Have you checked your error log?

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Change in module naming conventions

At 18:59 27.08.2002, David Wheeler wrote:
>On Tuesday, August 27, 2002, at 09:46  AM, Per Einar Ellefsen wrote:
>
>>It's actually Apache::Persistent, because the persistence modules in it 
>>have big differences from the Apache::Util modules.
>
>Oh. So what's the complaint about Apache::Util:: ?

Not having the Persistent:: modules in it. And if it would have them in it, 
Apache::Util wouldn't necessarily be a correct name. But I think we'll keep 
Apache::Persistent and Apache::Util as is.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Change in module naming conventions


At 18:38 27.08.2002, David Wheeler wrote:
>On Tuesday, August 27, 2002, at 09:29  AM, Per Einar Ellefsen wrote:
>
>>- I created the Apache::Util:: namespace. However, one person thought the 
>>Persistent:: namespace to be too specific, and would prefer to rename 
>>Apache::Util:: to something like ::Misc, ::Lib, ::Extensions or ::Addons, 
>>and add the Persistent:: modules there. What do you think?
>
>I like Apache::Util, and don't have a problem with 
>Apache::Util::Persistent. Makes sense to me.

It's actually Apache::Persistent, because the persistence modules in it 
have big differences from the Apache::Util modules.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Change in module naming conventions

Hi everyone,

This has already been posted on the dev list, but with no replies (however
previous feedback has been positive to this regard), so I'll pass it
through here for some feedback before going on with it.

To find out how the new namespaces would look, I have gone through the
process of categorizing all mod_perl modules found on CPAN (by searching
for the Apache:: prefix).

What I came to was this:
http://users.skynet.be/pereinar/mod-perl/modules.txt

NOTE: I am *not* suggesting we rename all existing Apache:: modules, that
issue has been raised many times before, and is clearly impractical. This
list is only to get an idea of what categories could possibly be needed.
Think of it as a way of wrapping my mind around what is already here.

From this, and some comments from other people, I have come to a set of
Module naming guidelines, which I just placed online for your perusal: see
here:
http://users.skynet.be/pereinar/mod-perl/products/apache-modules.html#Module_Naming_Conventions

Some questions I got which I'm not too sure of:
- I created the Apache::Util:: namespace. However, one person thought the
Persistent:: namespace to be too specific, and would prefer to rename
Apache::Util:: to something like ::Misc, ::Lib, ::Extensions or ::Addons,
and add the Persistent:: modules there. What do you think?
- I originally had Apache::Auth::Authen, ::Authz and ::Access, but Robin
Berjon told me he preferred to have the 4 as top-level namespaces. What do
people think?

--
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: large projects in mod_perl

At 09:16 27.08.2002, zt.zamosc.tpsa.pl wrote:
>Hi all
>
>Does anyone know where I can find some information on creating big projects
>in Perl (mod_perl)?
>I am facing the really big project now but I don't know what stucture of the
>program will be the best.
>
>There are such things like Struts, jBoss in Java. What about Perl?

Well, with mod_perl you have many possibilities. I would advise you to read 
http://perl.apache.org/docs/tutorials/apps/scale_etoys/etoys.html for an 
explanation about a big project involving mod_perl at EToys, and 
http://perl.apache.org/products/app-server.html for a list of application 
servers available for mod_perl (as well as maybe 
http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html to 
look at how to choose a templating system).

You might also want to develop your own architecture based on MVC, which we 
had a long discussion about here recently. For a lot of interesting 
reading, look at these threads:
o http://mathforum.org/epigone/modperl/jilgygland
o http://mathforum.org/epigone/modperl/pahphucree
o http://mathforum.org/epigone/modperl/solchaxzim
o http://mathforum.org/epigone/modperl/lerdginspir
o http://mathforum.org/epigone/modperl/stremnemcland
o http://mathforum.org/epigone/modperl/nounumspim
o http://mathforum.org/epigone/modperl/blildeudrand
o http://mathforum.org/epigone/modperl/zhathontimp
o http://mathforum.org/epigone/modperl/drehkrerlnen
o http://mathforum.org/epigone/modperl/drurflerdplald

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Nearing banner submission deadline

2002-07-03 Thread Per Einar Ellefsen


At 16:03 02.07.2002, you wrote:
>On Tue, 2 Jul 2002, Per Einar Ellefsen wrote:
>
> > Banners are now online!!
> >
> > We received banners from 3 persons, and they will all represent 
> mod_perl :)
> > However, if you have any new ideas and a little time, you are very welcome
> > to send in more banners, we always welcome those.
> >
> > See the banners online at:
> >  http://perl.apache.org/release/about/link/linktous.html
>
>The logo & banners and the buttons use a different version of the logo
>(with _ or without).  I don't care which one we use, but we should be
>consistant.  It's branding after all...
>
>The logo at the top of the page also uses a different weighting on the
>font, where the word 'perl' isn't as bold as the others.

Yes, thank you Marc.. We already know this, but have some slight problems 
with the logos. It will be fixed in due time, don't worry.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Nearing banner submission deadline

2002-07-02 Thread Per Einar Ellefsen


Banners are now online!!

We received banners from 3 persons, and they will all represent mod_perl :) 
However, if you have any new ideas and a little time, you are very welcome 
to send in more banners, we always welcome those.

See the banners online at:
 http://perl.apache.org/release/about/link/linktous.html

At 23:01 28.06.2002, Per Einar Ellefsen wrote:
>Hi,
>
>As I said in my previous post, we are looking for mod_perl banners. We 
>asked that you send in submissions before July 1st. However, we have only 
>received 2 entries.
>
>If anyone has any graphic capabilities (doesn't have to be much really, 
>the most important thing is just to get the message through with some 
>great text), we would really appreciate to receive some more banners.
>
>For more information, please see my earlier announcement:
>http://mathforum.org/epigone/modperl/swoubreldbrimp

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

[ANNOUNCE] New mod_perl site Release Candidate 1

2002-07-02 Thread Per Einar Ellefsen


What?
-

As you may know, the work on the new mod_perl site started in
September 2001, and after almost a year we are glad to present to you
the outcome of this work. The new site's goal wasn't only to create a
nice design, but mainly to improve its documentation organization and
navigational aspects, because of the ever growing amount of
documentation that the mod_perl community generates.

We have now come to the point where we are very satisfied with the
design and overall usability of the site, so we are proud to announce
the Release Candidate 1. Depending on the feedback from you, the site
may undergo some minor fixes if there are problems and will eventually
be released for you all to use.

Where?
--

RC1 is now located at this URL:

  http://perl.apache.org/release/

When the Release Candidate gets all its bugs rolled out, it will
replace the existing mod_perl site:

  http://perl.apache.org/

What Problems To Report?


Throughout development, the site has been tested extensively on many
different OS/browser combinations: Unix, MacOS and Windows. However,
we couldn't test with every possible browser/platform combination, so
it's possible that certain combinations are problematic.

This is why we ask for your help: take some time to browse the site,
and take note of:
- errors with browsers (crashes and/or rendering problems)
- usability: are you satisfied with the navigation and organization
   of the content?
- your general satisfaction with how the site is.

Before sending your feedback, please remember that the site has been
designed with respect to the HTML 4.0 and CSS 2 standards, and it is
therefore possible that the rendering might be flawed in some browsers
that do not follow these standards, either because they are old (and
these standards didn't exist at the time of their release) or simply
broken. However, we still tried to make the site usable for these
browsers, which also somewhat restricted us in deploying the standards
to their full extent.

So if you see a rendering problem in a browser that is known not to
support these standards, but the site is still usable, you may have to
live with that and possibly you will need to consider upgrading your
browser.

The text browsers "lynx" and "links" seem to work fine with the new
site, please report any problems with other text browsers that we
didn't have a chance to test with.

The punchline, is that you should remember that we don't claim that
the site is perfect and it's still much better than the existing
one. We will *not* try to provide a solution for every browser out
there, because we simply don't have the resources for that, and we
don't want to maintain a dozen css style sheets to accomodate for
idiosyncrasies of every browser. However, we do want to get it to work
as best as possible for everyone.

Also we would like to remind you that you've had many chances to
influence the overall design of the site and at this point it's too
late to suggest drastic changes, so please stick to bug reports since
we want to release the new site soon. If you've ideas for the future
generations of the site, please consider bringing them up after this
site is released.

Where to report?


Before reporting a problem, first please check whether the problem
that you've have been reported already here:

 http://perl.apache.org/ISSUES

If your issue is already listed, please do not submit it again.

For a list of working OS/browser combinations, see here:

 http://perl.apache.org/STATUS

Otherwise please post the description of the problem to the docs-dev
list:

  http://perl.apache.org/release/maillist/docs-dev.html

To post, send an e-mail to:

  docs-dev (at) perl.apache.org

You do not have to be subscribed to post, but your message will have
to be approved first so it might take some hours before it gets to the
list.

When reporting, we will need as detailed information as possible:
- Operating System's name and version
- browser's name and version
- a detailed report of the *exact* problem you are having
- if you have a rendering problem please provide a snapshot, though
   please try to keep the snapshot's size small.

If the site is working OK for you, and it's not listed at
http://perl.apache.org/STATUS , you can send us an "OK" report so that
we know what works and what doesn't.

Please be as precise as possible to help us find out the problem and
fix it. Furthermore, if you know hot to fix the problem, we will
appreciate that.

When the new site goes live?


If there will be no major bugs hopefully in about 1-2 weeks.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Mod_Perl Compilation with HPUX Native CC

2002-07-02 Thread Per Einar Ellefsen

At 11:02 02.07.2002, Chandrasekhar R S wrote:
>Hello everyone,
> I must compile Mod_perl on HPUX 11.0 with HPUX's native CC, 
> instead of gcc.
>
> Are there any configuration parameters need to be set such that 
> Mod_Perl is
>compiled using "cc".

I don't know if mod_perl will compile with HP-UX cc, but if you want to 
try, you must first of all have a perl binary compiled with cc. Then 
mod_perl should pick that automatically.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Trouble making mod_perl

2002-06-30 Thread Per Einar Ellefsen


At 13:06 30.06.2002, Eric wrote:
>Greetings!
>
>I've downloaded mod-perl-1.99_02 and am having trouble getting it to make.

What Apache version are you using? 1.99_02 is pretty old, you should get 
1.99_04 to work with the latest Apache.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: FW: mod_perl_make error

2002-06-29 Thread Per Einar Ellefsen


At 16:36 28.06.2002, Garrington, Richard wrote:
> /opt/ansic/bin/cc  -DHPUX11 -Aa -Ae -D_HPUX_SOURCE -DMOD_PERL 
> -DUSE_PERL_SSI  -D_HPUX_SOURCE +DD64 -Ae  +z -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64  -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite 
> -DNO_DL_NEEDED -D_HPUX_SOURCE +DD64 -Ae -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64 +z -D_LARGEFILE_SOURCE 
> -D_FILE_OFFSET_BITS=64  -DMOD_PERL\
>
>   -o httpd buildmark.o 
> modules.o  modules/perl/libperl.a  modules/standard/libstandard.a 
> main/libmain.a  ./os/unix/libos.a  ap/libap.a regex/libregex.a 
> lib/expat-lite/libexpat.a `/usr/bin/perl 
> /.cpan/build/mod_perl-1.27/src/modules/perl/ldopts  ` -lm -lpthread 
> -Wl,-E -Wl,-B,deferred  +DD64 -Wl,+vnocompatwarnings -L/usr/local/lib 
> -L/lib/pa20_64 
> /opt/perl5/lib/5.6.1/PA-RISC2.0-thread/auto/DynaLoader/DynaLoader.a 
> -L/opt/perl5/lib/5.6.1/PA-RISC2.0-thread/CORE -lperl -lcl -lpthread -lnsl 
> -lnm -ldld -lm -lc -lsec
>
>ld: Unknown input file type: "regex/libregex.a"
>Fatal error.
>*** Error exit code 1

This seems related to Apache and not mod_perl. You should ask at an Apache 
mailing list for help. Weird error though.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: What gives with $m->time in 1.10?

2002-06-29 Thread Per Einar Ellefsen


At 02:47 29.06.2002, David Dyer-Bennet wrote:
>It's in the doc for 1.05, not in the doc for 1.10, and I can't find
>any reference to it in the ChangeLog on the website, and it's not
>mentioned in the UPGRADE file.  My application, of course, is using
>it, for what I thought were going to be good reasons (ability to test
>date-dependent stuff through the preview interface).

This is Mason, right? You'll have better luck with your questions if you go 
to a Mason-list. See http://www.masonhq.com/resources/mailing_lists.html


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Like-named perl modules in separate directories

2002-06-26 Thread Per Einar Ellefsen


At 17:29 26.06.2002, Tim Gerla wrote:
>I've got a problem with a perl module (.pm) problem on my server. I've
>got two slightly different versions of a file: Conf.pm, in two separate
>places on my server. (Let's call them /home/www/docs/web/cgi/ and
>/home/www/docs/minos/cgi/) Mod_perl apparently keeps caching one or the
>other, causing interesting problems if I hit a 'web' script, and then a
>'minos' script a few minutes later.
>
>What's the best way to get around this?

RTFM :)
http://perl.apache.org/release/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs

You should read the whole mod_perl guide. You'll be out of questions 
afterwards :)


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: ANNOUNCE: Embperl 2.0b8


At 21:30 25.06.2002, Gerald Richter wrote:
>Hi,
>
> >
> > While I am not very familiar with Embperl, I saw some discussion
>concerning
> > PHP that struck me as pretty interesting for Embperl and similar
> > applications: have you considered making (or atleast having an option for)
> > Embperl an output filter for Apache 2/mod_perl 2? I think this would more
> > clearly show its purpouse, just like SSI is now really a filter under
> > Apache 2.0.
> >
>
>Yes, 2.0b8 can be a output filter for Apache 2.0, even more Embperl::Object,
>which allows you to create your site out of objects or components, can now
>not only include other Perl output, but any output that is created by a
>Apache request, you just use the subreq parameter to the Execute function
>(which is used to inlcude other parts), give it an URI and you have that
>part included in your page, regardless if it is a CGI script, output
>generated by PHP or Java or whatever runs inside Apache and of course you
>can postprocess the output that comes from other Apache components.

Ok, great then!

> > If there is already a way to filter output through Embperl, I'm sorry for
> > this useless post :(
> >
>
>Questions are never useless, this one for example gives me the chance to
>show one of the new feature of Embperl 2 :-)

:-) But I'm still sorry for not checking up enough.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: ANNOUNCE: Embperl 2.0b8

At 12:39 25.06.2002, Gerald Richter - ecos gmbh wrote:
>I have done a lot of fine tuning and error fixing since 2.0b7. Also Embperl
>now supports mod_perl 2.0 with prefork MPM (threaded MPM will require Perl
>5.8.0). The docs are moveing towards 2.0, but some features are still only
>documentent in README.v2.
>
>Everybody who is running a copy of Embperl 2, should upgrade to 2.0b8,
>because this will improve stabibility.

Hello Gerald,

While I am not very familiar with Embperl, I saw some discussion concerning 
PHP that struck me as pretty interesting for Embperl and similar 
applications: have you considered making (or atleast having an option for) 
Embperl an output filter for Apache 2/mod_perl 2? I think this would more 
clearly show its purpouse, just like SSI is now really a filter under 
Apache 2.0.

If there is already a way to filter output through Embperl, I'm sorry for 
this useless post :(

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Is mod_perl the right solution for my GUI dev?

At 16:09 25.06.2002, Ganesan M wrote:
>Hello list,
>
> Please pardon me if it is not related to the list.
>
>   We have a C application which runs on both SCO open server
>and Red Hat Linux with Oracle/Informix database. It is a text
>based application originally developed for CRDS box with UNOS.
>
>   Now management needs a GUI for the text application.I have
>developed some report screens using Apache/Mod_perl/GD.
>They kind of liked it.  Now they want to do a full fledged GUI.
>
>  My suggestions are:
>
> 1. Get rid  of screen driver codes from the existing C programs
> 2. Use "Inline C" in the mod_perl programs and run it through apache
>webserver as a web page.
>
>But, some of my colleagues are suggesting to write a Java/VC++
>Interface for the GUI.

The problem you're looking at is rather different: should you try and 
create a *web frontend* or should you create a normal GUI? Largely 
depending on the nature of your application, the answers will be different.

I can't say much more without knowing more about what you're trying to do: 
but to me it seems like if you need GD to do the job, you should probably 
be looking at a standard GUI instead. This needn't be done in Java or VC++, 
you could use any programming language with a windowing library, like Perl 
with Tk (or Gtk or Qt bindings, but I don't know much about any of those) 
or anything else.

My answer: it depends :)

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Win32 Binarys

At 14:15 25.06.2002, [EMAIL PROTECTED] wrote:
>Where can I get a Win32 binary of mod_perl?
>I use Apache 1.3.26/ActivePerl Build 522.
>None of Randy Kobes' PPMs would Install and the newest
>pre-compiled zipped binary is for mod_perl 1.16.

You probably want to get a new ActivePerl version. Build 522 is pretty 
outdated now. Newer binary versions of mod_perl won't install because they 
need ActivePerl 6xx.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Apache:: module organization and getting it to work with PAUSE


Hi Tim, thanks for replying,

At 22:33 23.06.2002, Tim Bunce wrote:
> > Why am I adressing you? Because Randy suggested, and I agreed, that some
> > kind of module listing in categories would be interesting for the modules
> > and for the mod_perl community--probably having a page dedicated to
> > mod_perl modules. However, we don't want one person to maintain such a
> > category: just like PAUSE exists to avoid one person to take care of all
> > CPAN modules, it would be preferable to get module authors to categorize
> > their modules themselves. This can only be done satisfactorily with PAUSE,
> > to handle password protection etc... So I'm wondering if this is doable:
> > for example, on the "Register namespace" page, there could be a category
> > called "mod_perl modules", which would then bring you to a second page
> > where you choose your mod_perl category.
>
>I'd be happy to see the Apache::* modules in section 15 (World Wide Web ...)
>moved into a new 'Apache' section (needn't be mod_perl specific, could
>include admin modules etc).
>
>I'm not sure how Andreas maintains 00modlist.long.html these days
>but there is clearly some 'sub-section' concept already in place
>("Apache PerlAuthzHandler modules", "Apache PerlAccessHandler
>modules" etc)

Yes, but those came from the original mod_perl module list.

>so it seems very reasonable that PAUSE should allow
>users to select which sub-section their module should be listed in.
>You could almost call it a bug that it doesn't already support it.
>
>The UI change ought to be as simple as adding the subsections to
>the "Module List Chapter" drop-down list (that currently contains
>just the 24 existing section names)

Yes, this would clearly be great. It's what I was hoping for. What do you 
think, Andreas? (assuming he gets this mail)


>.--

Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)

2002-06-23 Thread Per Einar Ellefsen


At 00:49 23.06.2002, Charles Aulds wrote:
>At 06:41 PM 6/21/02 +0200, Per Einar Ellefsen ([EMAIL PROTECTED]) wrote:
>
>>As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to:
>>1) make sure you are using the prefork MPM for Apache (as Stas said, 
>>Apache::DBI can only work with that one)
>>2) You will probably need to run mod_perl 2.0 in compat mode: put
>> PerlModule Apache::compat
>>in your httpd.conf, before loading other modules (like Apache::DBI).
>
>I didn't expect Apache::DBI to work under mod_perl 2.0, at least not well, 
>but was quite surprised.  Today, I got it to work with this server:

Great! Seems like Apache::compat is working as a charm.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: [JOB] Crack OOP Perl whitebox tester wanted

2002-06-22 Thread Per Einar Ellefsen


At 11:46 22.06.2002, Ged Haywood wrote:
>Hi all,
>
>On Fri, 21 Jun 2002, Zac Morris wrote:
>
> > Old fashioned is right,
>
>Can we decide whether this kind of post is or is not welcome on the List?
>
>My 0.02 is that if someone has decided on the terms of reference for
>an offer of employment which he is making then if it's legal, that's
>the way it has to be and we don't need to discuss it here - especially
>not at such length.

I agree with you Ged; Job announcements are ok, any discussion is way OT.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: [OT] Re: Apache Web Server vulnerability

2002-06-21 Thread Per Einar Ellefsen


At 20:06 21.06.2002, Philip Mak wrote:
>On Fri, Jun 21, 2002 at 05:31:00AM -0700, Ask Bjoern Hansen wrote:
> > 64bit binaries are exploitable.  There are also exploits for several
> > 32bit systems.
>
>Does anyone know if Red Hat Linux 7.2 on i686 is vulnerable to the
>remote shell (not the DoS) exploit?

I suggest bringing this up on the appropriate httpd lists instead. This 
thread has gone far enough IMO.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)

2002-06-21 Thread Per Einar Ellefsen


At 19:46 21.06.2002, Stas Bekman wrote:
>Per Einar Ellefsen wrote:
>>At 18:26 21.06.2002, Zac Morris wrote:
>>
>>>I actually have a question along these lines
>>>
>>>I'm new to mod_perl myself, and I've just installed a new setup with Apache2
>>>and the mod_perl2 beta.
>>>
>>>That's all working well and my old cgi-bin type stuff works under mod_perl
>>>great.
>>>
>>>Now I'm trying to get more into the mod_perl specific stuff and when I: use
>>>Apache::DBI I'm getting a can't find Apache.pm
>>>
>>>To use Apache::DBI do I need the old mod_perl 1 also installed running some
>>>kind of "dual mode"?  Or is that not even an option since I'm running
>>>Apache2.  I'm learning quick so if this is covered someplace just give me a
>>>quick pointer.
>>
>>As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to:
>>1) make sure you are using the prefork MPM for Apache (as Stas said, 
>>Apache::DBI can only work with that one)
>>2) You will probably need to run mod_perl 2.0 in compat mode: put
>> PerlModule Apache::compat
>
>but first you need:
>
>PerlModule Apache2
>
>or 'use Apache2' in startup.pl. see:
>http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules

Nope, he did a "clean" mod_perl 2 install, without MP_INST_APACHE2 I 
think... so doesn't have an Apache.pm because mod_perl 1 wasn't installed 
before.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)

2002-06-21 Thread Per Einar Ellefsen

At 18:26 21.06.2002, Zac Morris wrote:
>I actually have a question along these lines
>
>I'm new to mod_perl myself, and I've just installed a new setup with Apache2
>and the mod_perl2 beta.
>
>That's all working well and my old cgi-bin type stuff works under mod_perl
>great.
>
>Now I'm trying to get more into the mod_perl specific stuff and when I: use
>Apache::DBI I'm getting a can't find Apache.pm
>
>To use Apache::DBI do I need the old mod_perl 1 also installed running some
>kind of "dual mode"?  Or is that not even an option since I'm running
>Apache2.  I'm learning quick so if this is covered someplace just give me a
>quick pointer.

As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to:
1) make sure you are using the prefork MPM for Apache (as Stas said, 
Apache::DBI can only work with that one)
2) You will probably need to run mod_perl 2.0 in compat mode: put
 PerlModule Apache::compat
in your httpd.conf, before loading other modules (like Apache::DBI).

You will probably also want to see the 2.0 docs at 
http://perl.apache.org/release/docs/

Good luck!

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Naming convention for Apache 2 modules.


At 13:26 18.06.2002, Stas Bekman wrote:
>Andy Wardley wrote:
>>I've been playing around with Apache 2 and mod_perl 1.99 and considering
>>the changes I'll need to make to Apache::Template to make it play nicely
>>under the new world order.
>>Given that I want to continue to support Apache::Template for v1 users, 
>>should I create another module, say Apache2::Template, or is there some
>>preferred approach to v1/v2 compatabilities that I should consider?
>>I've read the compat.html doc and understand that I might be able to 
>>support Apache::Template as it is with the help of the Apache2 compatability
>>module.  However, I'm sure there are some parts, server/dir merging in 
>>particular (which seem to be broken in v1 anyway), which are going to need
>>new implementations for v2, so I figure it's probably worth forking the 
>>codebase sooner rather than later.
>
>No Andy, no need to rename, you can either maintain the two in one module 
>(if it's not too messy, which is the case if you have a lot of C) or just 
>two different versions which will install themselves into different dirs.
>
>Here are some preliminary notes discussing these issues.
>http://perl.apache.org/release/docs/2.0/devel/porting_from_1.x/porting_from_1.x.html
>Feel free to help improving on these.
>
>Of course the MP_INST_APACHE2=1 mechanism needs to become available to to 
>other module writers.

Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that 
using the CPAN.pm module to download the module would fetch the newest 
version of the module, regardless of whether you wanted the one for 
mod_perl 2.0 or mod_perl 1.0.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: [RFC] Change our habits in module naming?

At 13:22 18.06.2002, Stas Bekman wrote:
>[when suggesting things please give people some time to respond, 
>especially given the crazy traffic at this list lately. I just had a 
>chance to read this thread.]

Sorry.

>I'm -1 on renaming. Here is why:

I never talked about renaming. I talked about new modules.

>- Not all modules fit into suggested categories, some modules belong to 
>several ones.

Of course, but just like on "regular" CPAN you choose a category even if it 
might not be *exactly* the one you're looking for, it's possible to choose 
a namespace because it's what's most appropriate for a module. If there's 
really a problem, then a new namespace could be created, there's nothing 
wrong with that.

>- We definitely don't want the hell to break loose by pushing the authors 
>to rename their modules. Think of all the documents which aren't under our 
>control which refer to these module names! Books and articles to start with.

As I said, I didn't say we should rename existing modules.

>- This is also doesn't help with the move to 2.0, because many modules 
>will work with both versions without changes, or with some internal 
>changes transparent to users. It doesn't force authors to rename their 
>modules. And with the Apache2/ dir trick, there is no reason for doing 
>that at all.

The Apache2/ trick doesn't help *people* follow module namings. My proposal 
is mainly targeted at peoples' minds: we like organization, that's why we 
have namespaces in the first place!

>It'd be great though to have guidelines for developing Apache:: modules 
>and their name conventions. There feel free to suggest a better categorization.

Oops, didn't see this one :) Well, that was mostly my suggestion. It's just 
about the naming for new modules.

>And I'm -1 on maintaining a separate catalog. Here is why:
>
>CPAN is already categorizing Apache:: modules.
>http://www.cpan.org/modules/00modlist.long.html#ID15_WorldWideW (just 
>scroll down till you get to Apache::)
>all we need is to add #Apache and the problem solved. We have already 
>tried to maintain apache-modlist.html, which just didn't work, the file 
>was neglected and many new modules aren't there. Whereas they are in the 
>CPAN listing. May be instead of potentially wasting efforts here, the 
>effort should go to help improve 00modlist.long.html, so both Apache and 
>other Perl categories will benefit from this. I'm quite sure that Andreas 
>and folks who bring you CPAN will be glad to get any help in this 
>direction. Andreas please correct me if I'm wrong.

That's why I contacted [EMAIL PROTECTED] I feel too that this would belong 
in the Perl module listing (although that didn't appear clearly in my other 
e-mail), but my proposal to PAUSE was just there to allow module authors to 
do their classification.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Apache:: module organization and getting it to work with PAUSE


Hi people,

Time for a post that's a little different than your usual "New user" and 
"New module" e-mails :) I'm posting here since it seems like the most 
appropriate place to discuss these issues.

I adressed an issue on the mod_perl list lately concerning the Apache:: 
namespace organization. As you may know, all mod_perl modules are currently 
grouped under Apache::, which creates a pretty extensive mess now that 
there are many of them.

You can see the thread here: 
http://mathforum.org/epigone/modperl/skeldkendtrau . The RFC was generally 
well received, so I think we are going to go through with it.

Of course, we cannot change the current modules, but it would be preferable 
to get new modules to follow certain conventions, like others on CPAN.

Why am I adressing you? Because Randy suggested, and I agreed, that some 
kind of module listing in categories would be interesting for the modules 
and for the mod_perl community--probably having a page dedicated to 
mod_perl modules. However, we don't want one person to maintain such a 
category: just like PAUSE exists to avoid one person to take care of all 
CPAN modules, it would be preferable to get module authors to categorize 
their modules themselves. This can only be done satisfactorily with PAUSE, 
to handle password protection etc... So I'm wondering if this is doable: 
for example, on the "Register namespace" page, there could be a category 
called "mod_perl modules", which would then bring you to a second page 
where you choose your mod_perl category.

Just tell me what you think. It would be interesting to get this working.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Naming convention for Apache 2 modules.


At 11:31 18.06.2002, Andy Wardley wrote:
>I've been playing around with Apache 2 and mod_perl 1.99 and considering
>the changes I'll need to make to Apache::Template to make it play nicely
>under the new world order.
>
>Given that I want to continue to support Apache::Template for v1 users,
>should I create another module, say Apache2::Template, or is there some
>preferred approach to v1/v2 compatabilities that I should consider?
>
>I've read the compat.html doc and understand that I might be able to
>support Apache::Template as it is with the help of the Apache2 compatability
>module.  However, I'm sure there are some parts, server/dir merging in
>particular (which seem to be broken in v1 anyway), which are going to need
>new implementations for v2, so I figure it's probably worth forking the
>codebase sooner rather than later.

What about making the 2.0 module follow the conventions I posted about 
earlier? Something like Apache::Framework::Template?


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: [RFC] Change our habits in module naming?


At 18:01 16.06.2002, Perrin Harkins wrote:
> > >Also, a module map might be a good thing to create, i.e. an improved
> > >version of this: http://perl.apache.org/src/apache-modlist.html.
> >
> > Well, because the module list has now moved into the Perl Module List
> > entirely, we are removing it with the new site.
>
>What I meant was that since you can't expect all of the existing modules
>to change their names you could make a little directory page that
>follows the organization you're proposing and have it list the existing
>modules in each category.  Maybe not worth it, but it could be useful
>for newbies.

Yes, I see your point, but my proposal was loosely tied to the categories 
already existing here: 
http://www.cpan.org/modules/00modlist.long.html#ID15_WorldWideW (browse 
down to 'Apache'), so the classification has been done already.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: [RFC] Change our habits in module naming?

At 17:01 16.06.2002, Perrin Harkins wrote:
> > I have been thinking about a reorganization of the Apache/Perl modules
>for
> > a while, and have come to the conclusion that it would probably be a
>good
> > idea. Please tell me what you think about this proposal.
>
>Sounds fine to me.  I would suggest creating a brief document with
>naming guidelines that people can be referred to.
>
>Also, a module map might be a good thing to create, i.e. an improved
>version of this: http://perl.apache.org/src/apache-modlist.html.

Well, because the module list has now moved into the Perl Module List 
entirely, we are removing it with the new site. However, I have created a 
new document which takes over that task somewhat, here: 
http://perl.apache.org/release/products/apache-modules.html . That's where 
I was thinking to have the guidelines. As for the organization of the 
module list, I suppose that new modules that adapt these guidelines will be 
correctly organized into the Perl module list (because of their different 
namespaces).

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

RE: [RFC] Change our habits in module naming?

At 14:05 16.06.2002, Jonathan M. Hollin wrote:
>However, the major problem, as I see it is, is simply that people already
>KNOW modules by a specific name and changing them is probably going to lead
>to confusion and possibly even some bitterness.  If I'm setting up a new
>server I'm going to be mighty pissed to have to unlearn what I know about
>the mod_perl module namespace...
>
>If you think this can be overcome (symbolic links on CPAN anyone?), or if
>you see major support for your proposal, then you also have my vote.  I
>think your idea is sound and logical.  Nice one.

Yes, this is true. But I wasn't planning on making people change their 
current modules. That would clearly create confusion. This is a proposal 
for new modules which might come, especially for mod_perl 2.0

Which brings me onto another matter: I forgot some categories in my initial 
proposal. As for mod_perl 2.0 many new possibilities exist, I think we'd 
need something like:

Apache::Filter:: for native filters (and maybe split into Output/Input too?)
Apache::Protocol:: for protocol modules..

And probably some more I suppose. Anyway, as I said, this is indicative only.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

[RFC] Change our habits in module naming?


Hello,

I have been thinking about a reorganization of the Apache/Perl modules for 
a while, and have come to the conclusion that it would probably be a good 
idea. Please tell me what you think about this proposal.

What is the situation now?

Currently, all mod_perl modules are, as you know, grouped under the 
Apache:: namespace on CPAN. We have luckily come to have many of them, 
which is of course a great thing. However, this array of modules has 
created a lack of organization which leads to problems when you're trying 
to find your way around the Apache/Perl modules on CPAN. We have 
Apache::Log* modules, many Apache::Auth* modules, a number of frameworks, 
content handlers, and more...

Why do we need change?

I'm not sure if everyone feels like me, but for me, the Apache:: namespace 
is very much like a sub-section of CPAN. We have all kinds of different 
modules, but the only thing they have in common is that they run under 
mod_perl. However, on CPAN everything is nicely (or atleast mostly) 
organized into categories, like HTML::, Text::, Devel::, etc... Why can't 
we have such an organization for mod_perl modules too? With the advent of 
mod_perl 2.0, we have the occasion to change. For those who have followed 
mod_perl 2.0 development, you will have noticed that mod_perl now uses many 
namespaces: Apache::, APR::, ModPerl::. Let's follow the good form!

What do I suggest?

Like CPAN, there is of course no written rule when it comes to module 
naming. However, at one point we have to decide on the unwritten rules, so 
that they enter our culture. This is why I suggest the following 
organization (which is, as I said, open for comments), based on the 
different modules available for mod_perl now. We keep the Apache:: 
namespace, but create sub-categories:

Apache::Response:: for pure content handlers.
Apache::Auth:: for Authen, Authz and Access handlers
Apache::Type:: for PerlTypeHandlers (or the equivalent for mod_perl 2.0, 
whatever it is)
Apache::Framework:: for Application Servers/frameworks (along the lines of 
Mason, Embperl, etc, if these want to use the Apache:: namespace)
Apache::Log:: for log handlers.
Apache::Devel:: for anything development-related (Apache::DB for example, 
with any others.
Apache::Trans:: for PerlTransHandlers
Apache::Config:: for configuration-related things.
Apache::Monitor:: for monitoring tools (Apache::WatchDog, VMonitor, and 
maybe Apache::Status).

and maybe Apache::Util:: for modules that aren't handlers but useful when 
writing apps (like Apache::Session).

I suppose not everyone will agree with me on all these points, but let's 
try and focus and come to a conclusion here. Most of all, once we decide on 
something, it is important that future modules begin using these 
conventions: it's the only way to get it adopted.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

[1.27] Tests don't pass on Cygwin

2002-06-14 Thread Per Einar Ellefsen

gwin-multi
 uname='cygwin_nt-4.0 loreley 1.3.2(0.3932) 2001-05-20 23:28 i686 unknown '
 config_args='-de -Dusemultiplicity'
 hint=recommended, useposix=true, d_sigaction=define
 usethreads=undef use5005threads=undef useithreads=undef 
usemultiplicity=define
 useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
 use64bitint=undef use64bitall=undef uselongdouble=undef
   Compiler:
 cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing 
-I/usr/local/include',
 optimize='-O2',
 cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing 
-I/usr/local/include'
 ccversion='', gccversion='2.95.3-5 (cygwin special)', gccosandvers=''
 intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=4
 alignbytes=8, usemymalloc=y, prototype=define
   Linker and Libraries:
 ld='ld2', ldflags =' -s -L/usr/local/lib'
 libpth=/usr/local/lib /usr/lib /lib
 libs=-lgdbm -lcrypt
 perllibs=-lcrypt
 libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl5_6_1.a
   Dynamic Linking:
 dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
 cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'


Characteristics of this binary (from libperl):
   Compile-time options: MULTIPLICITY USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
   Built under cygwin
   Compiled at Aug 22 2001 01:05:05
   @INC:
 /usr/lib/perl5/5.6.1/cygwin-multi
 /usr/lib/perl5/5.6.1
 /usr/lib/perl5/site_perl/5.6.1/cygwin-multi
 /usr/lib/perl5/site_perl/5.6.1
 /usr/lib/perl5/site_perl
 .




-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Mapping to location "/"

2002-06-13 Thread Per Einar Ellefsen


At 16:04 13.06.2002, md wrote:

>--- Per Einar Ellefsen <[EMAIL PROTECTED]> wrote:
> > At 23:06 12.06.2002, md wrote:
>
> > I'm not quite sure about this, been wondering about
> > it, but in theory you
> > should be able to use
> > DirectoryIndex index.phtml
> > and like that you won't have to worry about "/" etc
> > anymore.
> > Try it out..
>
>And so I did...it won't work since mod_dir (as far as
>I can tell) looks for a physical file, and my
>index.phtml is virtual.

Ok, too bad.

>What I'm really trying to do is more like the PHP I'm
>replacing. I should be able to go to:
>
>www.someserver.com/index.phtml for a dynamic page
>and
>www.someserver.com/index.html for a static page.

Does PHP do that?

>I'm guessing that my best solution would be to use
>HTML::Mason or Apache::ASP instead of
>Template-Toolkit. However, I can' really do that...it
>took me a while to get the designers to use TT, and I
>doubt I can get them to change again.

Using HTML::Mason or Apache::ASP won't solve anything special. It's still 
the same basic thing.

>I may try using the PerlTransHandler to change the uri
>to a location...say with
>www.someserver.com/index.phtml the uri gets changed to
>/modperl (or www.someserver.com/somedir/index.phtml
>the uri becomes /modperl/somedir) which is used in a
> directive.

Let's assess your situation a litte: why can't you just put your TT 
templates into your document root, and do like with your PHP pages? That 
would solve the current problem you seem to be facing. Furthermore, have 
you looked into the Apache::Template module? I think it's pretty close to 
what you want.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: header woes

2002-06-13 Thread Per Einar Ellefsen

At 16:04 13.06.2002, Arnold van Kampen wrote:
>forgot the error message:
>
>Use of uninitialized value in join or string at (eval 9) line 16.
>  [ =  my $type = $table->{'Content-type'}; ]

Maybe because there is no Content-Type sent with a request unless it's a 
POST request? Content-Type is usually in the *outgoing* headers...

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: tutorials (was: Re: rfc Apache::Dynagzip)


At 00:04 13.06.2002, Slava Bizyayev wrote:

>From: "Stas Bekman" <[EMAIL PROTECTED]>
>Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip)
>
>
> > Probably the best post it here first, so we can get it reviewed and
> > commented on before we add it to the docs.
>
>Since now the draft tutorial "Features of Content Compression for Different
>Web Clients" (for Part IV: Client side facts and bugs) is available for
>preview and discussion at
>http://devl4.outlook.net/devdoc/Dynagzip/ContentCompressionClients.html .
>
>I strongly hope to make it much better with your help prior to submit for
>publishing. Any comments will be highly appreciated.

Looks great Slava! Seems to integrate the needed info. I guess those who 
know more about Gzip encoding can tell you more technically-wise, but as 
far as the general look it seems ok to me.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

[OT] Re: Using Active Directory and mod_perl


At 23:57 12.06.2002, John Whitnack wrote:
>Is there a way to access Active Directory with mod_perl ?

You question isn't specific enough. But if there's a way with Perl, you can 
apply the same principle to mod_perl. Look for things like that on Google. 
For example, I found: http://www.perl.com/pub/a/2001/12/19/xmlrpc.html or 
try something else...

Anyway, this isn't the right list (except if you were looking for a 
mod_perl-specific module that is).


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Mapping to location "/"


At 23:06 12.06.2002, md wrote:

>--- darren chamberlain <[EMAIL PROTECTED]>
>wrote:
>
> > If you use a translation handler, you can just
> > return DECLINED for
> > everything you aren't specifically handling, and let
> > mod_dir do it's
> > thing, instead of emulating it.
>
>I still would like to check first if there is an
>index.phtml template instead of going directly to the
>directory index files like index.html. Can I add my
>"virtual" index.phtml to DirectoryIndex so I don't
>have to look for it in my handler? I'm not quite clear
>on this one...but it might be once I read the guide on
>translation handlers :)

I'm not quite sure about this, been wondering about it, but in theory you 
should be able to use
DirectoryIndex index.phtml
and like that you won't have to worry about "/" etc anymore.
Try it out..


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Mapping to location "/"


At 19:14 12.06.2002, Per Einar Ellefsen wrote:
>

Sorry, make that LocationMatch

>...
>

And  of course.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Mapping to location "/"


At 19:08 12.06.2002, md wrote:

>--- Aaron Ross <[EMAIL PROTECTED]> wrote:
>
> > Would
> >
> >  
> >
> >  
> >
> > do the trick?
>
>No...the files don't actually exist under htdocs since
>I'm using Template-Toolkit.

Oh, so your .phtml things are really just TT templates?
What about:


...

complete the regex with what you want.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Mapping to location "/"


At 18:41 12.06.2002, md wrote:
>I'm replacing an exisiting PHP site with mod_perl and
>Template-Toolkit.
>
>I normally set up mod_perl to use a location like
>this:
>
>
>
>and set the handler to my mod_perl module.
>
>However, I need to map to "/" since I'm replacing a
>system where there are existing PHP files like
>www.someserver.com/index.php or
>www.someserver.com/about.php.
>
>I decided to do use
>
>
>
>to map to my main mod_perl script.
>
>The first thing it does is to check if the uri ends
>with a .phtml extension (or www.someserver.com or
>www.someserver.com/...same with subdirectories). If
>there is, I continue processing, otherwise I decline
>it and let Apache handle it.

Can't you just drop the  and use

   SetHandler 

or something like that? Seems like it would avoid some overhead for you.
However, I'm not sure if I understand what you mean with
  $uri =~ m!.*/[^\.]+$!) {

>If I have a .phtml (or a directory index) I check if I
>have a template. If I have a template TT takes over,
>if not I return DECLINED and let Apache take over.

Hmm, but if you don't have a template, then you have nothing to serve, right?

>httpd.conf
>-
>
> PerlSetVar websrc_root /usr/local/templates
>SetHandler  perl-script
> PerlHandler Test::MyModule
>
>
>Beginning of MyModule.pm
>-
># Get the uri
>my($uri, $uri2);
>$uri = $uri2 = $r->uri;
>$uri2 =~ s[^/][];  # remove the leading '/'
>
># We only want to see .phtml files, or urls that end
>with '/'
># or where the stuff past the last '/' doesn't contain
>any '.'s.
># We'll check the later two case for a template and
>then
># decline it if no template is found.
>unless ($uri =~ /\.phtml$/ or
> $uri =~ m!/$! or
> $uri =~ m!.*/[^\.]+$!) {
> return DECLINED;
>}
>
>Is this the best way to do this?

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: mod_perl/passing session information (MVC related, maybe...)


At 18:20 12.06.2002, John Siracusa wrote:
>On 6/12/02 12:17 PM, Perrin Harkins wrote:
> > James G Smith wrote:
> >> The nice thing about the context then is that customers can have
> >> multiple ones for multiple windows and they can have more than they
> >> have windows.
> >
> > How do you tie a context to a window?  I don't see any reliable way to
> > do it.  The only way to maintain state for a window (as opposed to
> > global state for a session) is to pass ALL the state data on every link.
>
>Nah, you could just shove a context param into all forms and links on each
>page, and store the actually (possibly large) context server-side, keyed by
>context id (and session id, see below)

But what if someone opens one of the links in a different window, and 
continue on the same pages as in the original window, but with different 
parameters? The session ID would be the same, the context id would be the 
same, but the params would be different, right?


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Porting to mod_perl and cookies are breaking. Why?

2002-06-10 Thread Per Einar Ellefsen


At 23:55 10.06.2002, Mark Korey wrote:

>We found the problem ... this was an odd one (aren't most!?!).
>Turns out that the path (i.e. $cgi->cookie(-path =>'/', ...); )
>was NOT being set. Guess we assumed that CGI.pm would default it to '/'.
>Setting that seemed to do the trick.
>We are using CGI.pm and did not need to "PerlSetupEnv On".

It's the default to have it On, that's why it got me wondering.

>I'm still not sure why this works differently under mod_perl.

Probably not mod_perl's fault at all, you might have been using a different 
path before (or maybe a different vresion of CGI.pm?)

>Semi-related to this, isn't $cgi->cookie just an API which
>uses $ENV{HTTP_COOKIE}?

CGI.pm has mod_perl-related code under the hood. I'm not sure if the same 
applies to CGI::Cookie (which is used for $cgi->cookie).

>What's the big advantage of Apache::Cookie?

It's C, so it's faster. It uses the Apache API. You won't have to do things 
like print $cgi->header(-cookie => ...), you just do $cookie->bake; But 
basically, you don't need it yet.

>I'd like to keep my code as flexible & compatible as possible
>so it will run under both standard CGI & mod_perl, at least
>while we work the kinks out of our mod_perl configuration.

In that case, just keep your current code. You'll only have the use for the 
likes of Apache::Cookie when you start moving to the Apache Perl API anyway.

>On Mon, 10 Jun 2002, Per Einar Ellefsen wrote:
>
> > At 05:43 10.06.2002, Mark Korey wrote:
> > >ENV{HTTP_COOKIE} does not contain a newly set cookie, often it
> > >still contains an old value when I try to change it (ie switch to a
> > >different user).
> > >Everything else appears to be working fine.
> >
> > If you're saying that $ENV{HTTP_COOKIE} is empty, you should set
> > "PerlSetupEnv On" in your Location section. See
> > http://perl.apache.org/release/docs/1.0/guide/config.html#PerlSetupEnv
> >
> > Could we see your code (an excerpt showing the problem)? You might be doing
> > something wrong when trying to set cookies. Furthermore, you should really
> > be using CGI.pm, CGI::Cookie or Apache::Cookie for your cookie needs.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Porting to mod_perl and cookies are breaking. Why?

2002-06-09 Thread Per Einar Ellefsen

At 05:43 10.06.2002, Mark Korey wrote:
>ENV{HTTP_COOKIE} does not contain a newly set cookie, often it
>still contains an old value when I try to change it (ie switch to a
>different user).
>Everything else appears to be working fine.

If you're saying that $ENV{HTTP_COOKIE} is empty, you should set 
"PerlSetupEnv On" in your Location section. See 
http://perl.apache.org/release/docs/1.0/guide/config.html#PerlSetupEnv

Could we see your code (an excerpt showing the problem)? You might be doing 
something wrong when trying to set cookies. Furthermore, you should really 
be using CGI.pm, CGI::Cookie or Apache::Cookie for your cookie needs.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: tutorials (was: Re: rfc Apache::Dynagzip)

2002-06-06 Thread Per Einar Ellefsen


At 03:37 06.06.2002, Slava Bizyayev wrote:
>It's going to be something like "Features of Content Compression for
>Different Web Clients" for Part IV: Client side facts and bugs. We'll be
>able to discuss details next week.

Ok, great Slava, thanks a lot!


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: rfc Apache::Dynagzip

2002-06-05 Thread Per Einar Ellefsen

At 15:36 05.06.2002, Valerio_Valdez Paolini wrote:

>On Tue, 4 Jun 2002, Slava Bizyayev wrote:
>
> > I don't know should it be a kitchen of every system administrator, or
> > somebody could volunteer to serve the public web site about the current
> > conditions of different web clients and recommended masks?.. I can't 
> host it
> > on my devl4, because it is a development machine. That would be better to
> > find some stable place, like mod_perl, or apache project ;-).
>
>Can you provide a compatibility list? I think that the new mod_perl site
>is looking for new articles, may be the first part of Apache::Dynagzip
>man page is a good candidate... You could add also known bugs and
>features. But I cannot decide what goes on mod_perl site :)

Just like I would have said it myself :-) We're clearly looking for 
information, and I was especially watching this thread for possible 
inclusion. We have a nice place to do this, it's in our "Browser bugs" 
section. Depending on the size of the document, it might go there or in its 
own doc. Anyway, we welcome any submissions. Format is standard Pod. See 
http://cvs.apache.org/viewcvs.cgi/modperl-docs/admin/style.pod?rev=1.8&content-type=text/vnd.viewcvs-markup

for style information, but don't worry too much about that, we'll fix that 
as we go.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Re: Apache->server_root_relative(); not found

2002-06-04 Thread Per Einar Ellefsen

At 13:30 04.06.2002, m31 wrote:
>Well, I printed out my @INC to screen, and now I have directories that do 
>not exist in it from putting the wrong path in the server_root_relative 
>method, can any-one tell me how to remove this dir from @INC?  I treid a 
>few ways but to no sucess.

Restart your server? "use lib" doesn't make any permanent changes to @INC, 
these only persist across the httpd mod_perl run. If you restart (with the 
correct code this time), it should be set to the correct value.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Apache->server_root_relative(); not found

2002-06-03 Thread Per Einar Ellefsen

At 02:16 04.06.2002, m31 wrote:
>I am running OSX 10.1.4/Darwin. Dont think that has anything to do with it 
>though.

It might. It has been stated on the dev list that the "lib" pragma has a 
problem under Darwin. Could you try:
BEGIN {
 unshift @INC, Apache->server_root_relative('lib/perl');
}

?

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: htaccess, rewrite and redirect help please

2002-06-03 Thread Per Einar Ellefsen

At 17:54 03.06.2002, Paul Williams wrote:
>Hi all,
>
>I'm so new to this, please excuse me if i'm off base.
>
>I'm trying to write an htaccess script which will essentially say "If 
>you're from this web page you get rejected, but all other web page 
>requests go here:"

Sorry, but this is specific to Apache, not to mod_perl. Look at Apache 
mailing lists or newsgroups for answers: 
http://httpd.apache.org/lists.html#http-users

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Problem: Internal redirection of ErrorDocument to mod_perl handler

2002-06-03 Thread Per Einar Ellefsen


At 15:42 03.06.2002, Igor Sysoev wrote:
>On Sat, 1 Jun 2002, Richard Clarke wrote:
>
> > Before I present a detailed description of the problem I thought I'd
> > just bounce of an intro to see if its a common "fault".
> > I have found, using apache 1.x latest and mod_perl 1.x latest that if I use
> > internal redirection to a mod_perl handler for ErrorDocument 500
> > (server_error) then even though I return the perfectly correct data (html
> > headers etc) to the browser, every browser works fine. Except that is,
> > Internet Explorer 6 (maybe earlier too but I have no test bed). Internet
> > Explorer chooses to display the default Microsoft internal server error 
> page
> > and not the html which is actually returned. If I use a network monitor 
> like
> > Iris I can see that the data is returned perfectly...but Internet Explorer
> > refuses to display it. This problem my apply to other error codes. The only
> > fix I found is to use a fully qualified host redirect for the
> > ErrorDocument.. but then I lose fancy stuff like previous request analysis.
> > Any ideas?
>
>You error response size should be more then 512 bytes:
>http://support.microsoft.com/support/kb/articles/Q294/8/07.ASP

I just added a note about this in the documentation, under 
docs/tutorials/browserbugs. I had encountered this error before, and it 
seems like a surprising enough pitfall to be documented.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

RE: separating C from V in MVC

2002-06-01 Thread Per Einar Ellefsen


At 21:14 01.06.2002, Jeff wrote:
> > From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]]
> > Sent: 01 June 2002 18:10
> > To: Jeff
>
> > Well, as I see this, it isn't a problem. The layout manager takes
> > the place of the view, as it essentially decides how things should
> > be rendered. You then have two stages in your view, but the same
> > techniques apply (as the 2nd stage of the view isn't really specific
> > to any model or controller).
>
>This is my current thinking. Now that I have heard more details from
>the MVC folks on the list, I will have to sit down and spend some
>mental effort in assimilating MVC+template into what we currently
>do, and see what sort of beast emerges.

Well, as you see, MVC is more something of a way of thinking. I guess it's 
up to everyone to adapt it to their own needs. You decide what you think is 
best, but your "layout manager" idea clearly brings new light to this 
discussion.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

RE: separating C from V in MVC

2002-06-01 Thread Per Einar Ellefsen


At 15:09 01.06.2002, Jeff wrote:

> > From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
> > Sent: 01 June 2002 00:17
> > To: Rob Nagler
> > Cc: [EMAIL PROTECTED]
>
> > The same template?  How does the layout manager help with that?
> > Does it modify the template?  It would make more sense to me if
> > this were a sort of abstraction to factor out common layout
> > ideas from multiple templates.
>
>The layout manager is more complex than a static template. It takes
>a collection of data and meta-data and creates a document tree that
>is not a specific rendering flavour - the DOM might subsequently
>be rendered in NS4.0 HTML, IE5.01+ HTML, Excel, PDF etc. without
>requiring (every page) x (every format) x (every option) templates.

Well, as I see this, it isn't a problem. The layout manager takes the place 
of the view, as it essentially decides how things should be rendered. You 
then have two stages in your view, but the same techniques apply (as the 
2nd stage of the view isn't really specific to any model or controller).

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Video On Demand Project

2002-06-01 Thread Per Einar Ellefsen

At 09:20 01.06.2002, Medi Montaseri wrote:
>Please let me know if I should post this to some other (more) relevant
>group.

I think this very little mod_perl related. I don't think it's a good idea 
using mod_perl for that purpose either. You should try to find a video on 
demand mailing list of newsgroup. There must be people who know more about 
these things.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Apache::TicketAccess

2002-05-31 Thread Per Einar Ellefsen


At 21:50 31.05.2002, Arnold van Kampen wrote:


>Hi
>
>Where did it go?

The modules written for the Eagle book haven't been released to CPAN. They 
are available online. See 
http://modperl.com:9000/book/source/apachemod-code-1.02/lib/Apache/


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: mod_perl error

2002-05-31 Thread Per Einar Ellefsen

At 19:42 31.05.2002, Boex,Matthew W. wrote:

>can i ignore this error?  the script seems to work fine...
>
>Subroutine print_get_num redefined at /var/www/perl/cancel.cgi line 19.
>Subroutine print_gonna_del redefined at /var/www/perl/cancel.cgi line 27.
>Subroutine print_do_nothing redefined at /var/www/perl/cancel.cgi line 74.
>Subroutine print_do_del redefined at /var/www/fosbow/cancel.cgi line 83.
>Subroutine error_handler redefined at /var/www/fosbow/cancel.cgi line 156.

It depends. These errors are related to the following pitfall (I think): 
http://perl.apache.org/release/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs
You should read through that and find out how you can make your errors 
disappear and make your code more mod_perl friendly.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: PerlWarn/AxKit - insecure dependency

2002-05-29 Thread Per Einar Ellefsen

At 16:00 29.05.2002, Arnold van Kampen wrote:

>Hi
>
>I have been going through the code example on www.perl.com
>(XSP, Taglibs and Pipelines)
>
>I  noticed I get a problem with
>PerlWarn On
>PerlTaintCheck On
>in httpd.conf.
>So, when I turn PerlWarn Off and PerlTaintCheck Off it works.
>
>Main error message:
>[AxKit] [Error] Insecure dependency in eval while running with -T switch
>at /usr/lib/perl5/site_perl/5.6.1/i586-linux/Apache/AxKit/Language/XSP.pm
>line 109.

This is AxKit and not mod_perl's fault. AxKit doesn't seem to be taint 
safe. You might want to get them to change it (unlikely, it'd be a pretty 
long job :) or turn off PerlTaintCheck.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: dso

2002-05-29 Thread Per Einar Ellefsen

At 11:41 29.05.2002, Arnold van Kampen wrote:

>Hi
>
>Some messages ago, someone still mentioned that modperl had been
>  - compiled in -,
>when describing his configuration, that he was having trouble with.
>
>Does this mean it is still better to compile it in instead of
>using mod_perl as a dso?

If you're having problems, it's often known to be the quick answer to try. 
If you're not having trouble, keep using DSO happily!

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: mod-perl_2.0

2002-05-29 Thread Per Einar Ellefsen

At 00:25 29.05.2002, Kent, Mr. John wrote:
>Now my question.  In the older version,(126) mod-perl created a larger
>(heavy)
>webserver.  I could then add a startup.pl file to its http.conf file
>which used Apache::Registry to load perl and my modules.
>
>I don't see how this works in the new version of mod-perl, because
>I don't see a "larger" version of the httpd server anywhere.
>
>When I did the install it just seemed to load into the Perl 5.6.1 libraries.

We'll need some more information about your build process... Normally, you 
specify the Apache Prefix (or the location of apxs) when running perl 
Makefile.PL. Then, you run make for mod_perl, ./configure and make for 
Apache 2.0, make test for mod_perl and I guess finally make install on both 
parts.

You should see the mod_perl 2 installation documents: 
http://perl.apache.org/release/docs/2.0/user/index.html

>Did notice in the overview
>"The details of these optimizations from the most part are hidden from
> mod_perl users, the exception being that some will only be turned on
> with configuration directives. A few of which include:
> *   Inlined "Apache::*.xs" calls
>"
>But not sure how to use it.

This isn't really related to your question.. Look through the 
documentation, but for the most part these optimizations happen without you 
noticing.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Referencing Directives

2002-05-27 Thread Per Einar Ellefsen


At 21:13 27.05.2002, Ian D. Stewart wrote:
>Is it possible to reference the value of one Directive within another 
>Directive (e.g., PerlSetVar VariableName ${DocumentRoot}/subdir) ?

If you use  sections, yes.


$DocumentRoot = '/home/httpd/htdocs';
push @PerlSetVar, [ VariableName => "$DocumentRoot/subdir"];


Note that you need to set $DocumentRoot in a  section as well.

You might want to look at mod_macro too.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Need information from all contributors

2002-05-26 Thread Per Einar Ellefsen


Hi everyone,

I'm in the process of creating a Contributors page for the new mod_perl 
site. I have already gotten the old CREDITS file from modperl CVS, so I'm 
using that one. But it'd be nice to have some more information, such as 
name, e-mail address, home page URL, maybe a picture and most importantly 
information about what you have contributed to mod_perl. Right now I'm sure 
I'm missing many people, as the list must be pretty incomplete.

So, please go ahead and send me as much information about yourself as you 
want, whatever the contribution you have made: documentation, code, modules...

The list will look pretty much like the Apache one, so if you send me all 
the information people have at http://httpd.apache.org/contributors/ , that 
would make me happy :)

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

The Apache/Perl Module List listing modules which aren't on the CPAN?

2002-05-25 Thread Per Einar Ellefsen


Hi,

While editing a document for the new site I wanted to add reference to some 
CPAN modules. Well, the problem is that the Apache/Perl Module list 
contains references to some modules (mostly those coming from the Eagle 
book) which aren't available from the CPAN (atleast they don't appear when 
using the CPAN search).

So, should we:
1) Add these modules to the CPAN (they are after all pretty useful)
2) Remove them from the Apache/Perl module list

?

On a side note, I was wondering if the Apache/Perl module list is complete? 
Are there some modules missing?


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Strange subrequest dir_config issue

2002-05-24 Thread Per Einar Ellefsen

At 12:38 24.05.2002, Matt Sergeant wrote:
>Well it all made sense to me anyway - I just thought it should be
>documented ;-)

Thanks a lot Matt and Geoffrey, I have added this to the documentation 
(waiting for Stas to commit it).

It seems to me that it's a more general problem with assuming too much 
about  blocs. When you call lookup_file(), the URI isn't known, 
so  blocks aren't processed. This means that if you were 
pretending to call a mod_perl script run under Apache::Registry, it won't 
actually run under Apache::Registry either (if you configured with a 
 block that is). The solution as you said is using  
and  for these rare cases.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: mod_perl benchmarking (was Re: documenting SetHandler perl-script|modperl)

2002-05-23 Thread Per Einar Ellefsen


At 16:41 23.05.2002, David Jacobs wrote:
>I've had trouble benchmarking some of my mod_perl scripts on my desktop. 
>The http_load tool we usually use (all under RedHat) works fine with 
>static pages or CGI, but when I use it on mod_perl scripts I get a "byte 
>count wrong" error. This could be because of something unexpected in the 
>header, or perhaps mod_perl doesn't like to be benchmarked? It makes no 
>sense to me either :(
>
>What tools do you all use to benchmark web page performace?

This should be discussed on the mod_perl users list.

See the performance docs, 
http://perl.apache.org/release/docs/1.0/guide/performance.html
And especially the section on Benchmarking applications: 
http://perl.apache.org/release/docs/1.0/guide/performance.html#Benchmarking_Applications



-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Getting mod_perl to work under Win2k

2002-05-21 Thread Per Einar Ellefsen


At 19:51 21.05.2002, Michael Lawrie wrote:
>Hello,
>I've spent several days working on this problem, reading various FAQ and
>whatnot and finally decided to try this email list, hoping that I might find
>an answer here.
>
>I'm running Win2KPro and Apache 1.3.23
>I downloaded mod_perl2.ppd, and installed the *.so file in the default modules
>directory for my web server.

mod_perl 2 doesn't work with Apache 1.x.x
Apache 2.x doesn't work with mod_perl 1.xx

You'll need to get the mod_perl.ppd, like:
 > ppm install http://theoryx5.uwinnipeg.ca/ppmpackages/mod_perl.ppd

It should run an auto-install script at the end which puts mod_perl.so in 
the right location.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Memory Leaks


At 00:45 21.05.2002, Issac Goldstand wrote:
>I'd like to try to disagree here.  I have built several file-related 
>webapps where I have implemented virtual filesystems which require special 
>perl modules to access the files at all.  mod_perl takes care of serving 
>the requests.  If I need a restart, then I can still safely use 
>graceful.  Admittedly there are times when something could very well get 
>screwed up, but my solution to that is to develop a better front-end 
>server with it's own buffer so that the back-end can swiftly serve the 
>files leaving much more idle time (in comparison to directly connecting 
>remote client to fileserver) for  backend restarts if needed.

In the case that you need advanced logic such as that, I clearly agree with 
both you and Allen. And a proxy server is very needed in such a case :)

>Per Einar Ellefsen wrote:
>
>>At 23:54 20.05.2002, Allen Day wrote:
>>
>>>I've noticed that if I restart apache while I'm in the middle of a
>>>download (MP3 stream), after the buffer in my MP3 player runs out, it
>>>skips to the next track -- presumably because the connection was closed.
>>>
>>>This might cause a problem for you if your users are downloading big
>>>files.  They might have to restart from the beginning if they didn't cache
>>>the partial download somewhere.
>>
>>
>>Hmm, if you are serving big files off of mod_perl, memory leaks are the 
>>least of your problems :) That doesn't apply to Apache::MP3 of course, 
>>for which it's normal, but in no case should your mod_perl server be 
>>serving your big files.
>>
>>>On Mon, 20 May 2002, Matt Sergeant wrote:
>>>
>>> > On Monday 20 May 2002 9:30 pm, Gregory Matthews wrote:
>>> > > I too thought of setting a cron job to restart the server once per 
>>> day in
>>> > > order to keep the memory "fresh".
>>> > >
>>> > > In a production environment, are there any downsides to doing this, 
>>> i.e.,
>>> > > server inaccessibility, etc..?
>>> >
>>> > It's very rare to have a site that can't cope with just a few seconds
>>> > downtime. Most users won't even notice, save for some slight delay in 
>>> getting
>>> > their request through. Users tend to be pretty used to trying again 
>>> in this
>>> > world of "reliable" computing.
>>
>>--
>>Per Einar Ellefsen
>>[EMAIL PROTECTED]

Re: Memory Leaks


At 23:54 20.05.2002, Allen Day wrote:
>I've noticed that if I restart apache while I'm in the middle of a
>download (MP3 stream), after the buffer in my MP3 player runs out, it
>skips to the next track -- presumably because the connection was closed.
>
>This might cause a problem for you if your users are downloading big
>files.  They might have to restart from the beginning if they didn't cache
>the partial download somewhere.

Hmm, if you are serving big files off of mod_perl, memory leaks are the 
least of your problems :) That doesn't apply to Apache::MP3 of course, for 
which it's normal, but in no case should your mod_perl server be serving 
your big files.

>On Mon, 20 May 2002, Matt Sergeant wrote:
>
> > On Monday 20 May 2002 9:30 pm, Gregory Matthews wrote:
> > > I too thought of setting a cron job to restart the server once per day in
> > > order to keep the memory "fresh".
> > >
> > > In a production environment, are there any downsides to doing this, i.e.,
> > > server inaccessibility, etc..?
> >
> > It's very rare to have a site that can't cope with just a few seconds
> > downtime. Most users won't even notice, save for some slight delay in 
> getting
> > their request through. Users tend to be pretty used to trying again in this
> > world of "reliable" computing.

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Memory Leaks


At 23:23 20.05.2002, Gregory Matthews wrote:
>Unfortunately, we only have one machine.  If we did employ the cron job as 
>a clean-up utility once per day, wouldn't the potential impact of a site 
>being unavailable only be for a few seconds (until Apache restarted)?

And if something goes wrong? You'd be having a server offline with noone 
knowing about it.

>At 05:12 PM 5/20/2002 -0400, you wrote:
>
>>Like another suggestion, we have a cluster of machines and roll the
>>restarts every hour.  Each machine is offset but 10 minutes.
>>
>>Gregory Matthews writes:
>> > I too thought of setting a cron job to restart the server once per day in
>> > order to keep the memory "fresh".
>> >
>> > In a production environment, are there any downsides to doing this, i.e.,
>> > server inaccessibility, etc..?
>> >
>> > Thanks.
>> >
>> > Gregory
>> >
>> > At 08:25 AM 5/20/2002 -0400, you wrote:
>> >
>> > >It is more an issue of it being worth tracking down a small memory
>> > >leak vs a large memory leak.  Our software still has some very small
>> > >leaks, on the order of 10kv every hour...  it would probably take us a
>> > >month to track down and solve all these problems.  I find it easier to
>> > >restart the web servers daily.
>> > >
>> > >We did have some enourmous leaks as well, based on circular reference,
>> > >and those ate up 1 GB of memory in about 30 minutes...  It took us
>> > >about three weeks to find it.
>> > >
>> > >Gregory Matthews writes:
>> > > > So am I being overly paranoid concerning the "leak" potential of 
>> mod_perl
>> > > > programming?
>> > > >
>> > > > If I start with "strict" code to begin with and try my best to 
>> stay away
>> > > > from the problems you mentioned, then any potential memory leak/drain
>> > > > issues will be avoided?
>> > > >
>> > > > Keep in mind, although my application is not designed to launch 
>> the space
>> > > > shuttle, I do want it to be solid/stable/peformance-packed from the
>> > > ground up.
>> > > >
>> > > > I will be also be using MySql with the Apache::DBI module.
>> > > >
>> > > > Thanks in advance.
>> > > >
>> > > > Gregory
>> > > >
>> > > >
>> > > > At 11:34 PM 5/19/2002 -0400, you wrote:
>> > > > > > I have a couple of questions regarding leaking memory in mod_perl:
>> > > > > >
>> > > > > > 1.  What are the main culprits, in order of severity, of 
>> memory leaks,
>> > > > >i.e.:
>> > > > > >
>> > > > > > a.  global variables (NOT lexically scoped via my)
>> > > > > > b.  ...
>> > > > > > c.  ...
>> > > > > >
>> > > > > > 2.  When writing code from scratch (a new application), what 
>> is the
>> > > > >best
>> > > > > > way to avoid creating leaks to begin with, i.e., use strict;, 
>> PerlWarn
>> > > > >On,
>> > > > > > etc.. ?
>> > > > >
>> > > > >There are actually not very many ways you can leak memory in Perl 
>> (and
>> > > > >thus mod_perl).  Most people confuse memory growth with memory 
>> leakage.
>> > > > >If you want to know how to avoid memory growth, look at the 
>> performance
>> > > > >tuning stuff in the Guide, like passing references, avoiding 
>> slurping of
>> > > > >large files, controlling the buffering of DBI result sets, etc.
>> > > > >
>> > > > >Leaks are caused by circular references, the string form of eval (at
>> > > > >least it used to leak a little), nested closures (sometimes created
>> > > > >accidentally with the Error module), and one or two obscure syntax
>> > > > >problems.  I think one of them involved code like "my $x = 7 if $y;".
>> > > > >Matt Sergeant got bitten by this in the early stages of AxKit
>> > > > >development, and the details are in the mailing list archive.
>> > > > >
>> > > > >Global variables by themselves are not a source of leaks or 
>> growth.  If
>> > > > >you slurp a large file into a global, your process will grow, but the
>> > > > >same is true for a lexical.
>> > > > >
>> > > > >- Perrin
>> > > >
>> > > >
>> > >
>> > >--
>> > >C Wayne Huling <[EMAIL PROTECTED]>
>> >
>> >
>>
>>--
>>C Wayne Huling <[EMAIL PROTECTED]>
>
>

-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Monitoring the processes