from:"Per Einar"


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

 script type=text/pascal src=another.doc/script

or

 link rel='stylesheet' type='text/css' href='outside.css'/

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]

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: evil scripts kill the server...


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: 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]

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: 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 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: 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: 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: 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: 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: 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: 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 img src=\ thefile.jpg\  ;



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 img src=\ ../graphics/thefile.jpg\  ;

[...]

print img src=\ 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 img 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: 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


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: 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: 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]

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: 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]

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: 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 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: 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: Nearing banner submission deadline

2002-07-04 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: 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]

[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: 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]

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: [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: 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]

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: [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]

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?

2002-06-16 Thread Per Einar Ellefsen


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?

2002-06-16 Thread Per Einar Ellefsen


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]

[1.27] Tests don't pass on Cygwin

2002-06-14 Thread Per Einar Ellefsen

 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: 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: 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
Location /modperl 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: 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: 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:

Location /something

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

Location /

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 Location and use
Files *.phtml
   SetHandler 
/Files
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
-
Location /
 PerlSetVar websrc_root /usr/local/templates
SetHandler  perl-script
 PerlHandler Test::MyModule
/Location

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: Mapping to location /


At 19:08 12.06.2002, md wrote:

--- Aaron Ross [EMAIL PROTECTED] wrote:

  Would
 
   Files *.phtml
 
   /Files
 
  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:

Location .*\.phtml|/
...
/Location
complete the regex with what you want.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Mapping to location /


At 19:14 12.06.2002, Per Einar Ellefsen wrote:
Location .*\.phtml|/

Sorry, make that LocationMatch

...
/Location

And /LocationMatch of course.


-- 
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: 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]

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

2002-06-10 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: 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: 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.8content-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: 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: 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: 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: 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: 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: 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_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: 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: 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: 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 Perl sections, yes.

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

Note that you need to set $DocumentRoot in a Perl 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 Location blocs. When you call lookup_file(), the URI isn't known, 
so Location 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 
Location block that is). The solution as you said is using Directory 
and Files 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]

Apache::DBI debugging (was: Re: Modifying @INC via startup.pl)



At 23:36 19.05.2002, Gregory Matthews wrote:
# Initialize the database connections for each child
Apache::DBI-connect_on_init
(DBI:mysql:database=test;host=localhost, user,password,
{ PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 1, # commit executes immediately }

I am also using the $Apache::DBI::DEBUG = 2; flag to ensure it is working 
properly.

I am NOT seeing the entries in the error_log both when Apache::DBI 
initializes a connection and when it returns one from its cache.

Shouldn't I be able to see a reference to the connection in my error_log 
file?

I checked both my virtual host error_log file and the server error_log 
file. Nothing in either.

When/Where are you setting this flag? I don't have much experience with 
Apache::DBI, so I won't be able to help you much.

You could also try
 DBI-trace(1); #or any other level mentioned in the DBI docs.


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: building mod_perl_1.99_01,


At 13:47 20.05.2002, H Jayakumar wrote:
Hello anyone,

Iam building mod_perl for NetWare.

The new mod_perl ( 1.99_01 ) has extensions, under the wrapxs and the
xs directories.

I have built mod_perl.so .in the src/modules/perl directory.

What should I do next , to get the complete mod_perl ?

You should follow the instructions at 
http://perl.apache.org/release/docs/2.0/user/install/install.html

It would be interesting to see mod_perl work on Netware. If there are any 
platform-specific steps you come over, please share them!


-- 
Per Einar Ellefsen
[EMAIL PROTECTED]

Re: Monitoring the processes


At 22:50 20.05.2002, Gregory Matthews wrote:
Thanks to everyone for the great input on Memory Leaks.  Now that I have a 
good starting point for tracking down the problem, when I TEST for leaks, 
or simply check for a continued increase in server memory usage, how do I 
go about monitoring the processes growth?

For example, is there a command line tool to use that will allow me to see 
the process growth upon request reload?  I know that I should run the 
server with httpd -X, but I don't know how to actually see the memory 
being used/increased/decreased when the prog is being executed. As I 
understand it, this is a good indication that there might be a problem.

What about using top(1) on Unix systems?


-- 
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: 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