RE: Simple question about tables [OT]

2000-12-05 Thread Rufus . Cable

Sounds like you want a union query...

SELECT something, something_else FROM table1
UNION
SELECT something, something_else FROM table2

I think some databases are pickier than others about each pair of fields
being of the same datatype; Oracle requires each field to return the same
number of fields, while I seem to recall MS Jet doesn't... For mismatched
numbers of columns, do something like:

SELECT something, '' FROM table1
UNION
SELECT something, something_else FROM table2

If it's fussy about datatypes, using '', 0, null, sysdate, to_char() or
similar things to match the datatypes of the corresponding fields should
keep it happy...

hth
Rufus.

-Original Message-
From: bari [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 04, 2000 10:57 PM
To: [EMAIL PROTECTED]
Subject: Simple question about tables


Hi there,
I have two query's both have same # or rows as out put but have different
columns. Like the first query gives me like 4 columns and the second query
gives me 1 column as out put.. Now I want to club the results of both the
queries so that the resulting table is 5 rows.
I am able to display the result of each query in separate table.. Like I am
able to display the result of first query which is 4 columns in one table.
and the result of second query with one column as separate table.  but I am
not able to add the an extra column to first query so that it gives me an
option to display result of the second query.
it would be great if any one can help me.

Thank You

-bari


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl with threaded Apache (eg Apache2)

2000-12-05 Thread David Hodgkinson

"John K. Sterling" [EMAIL PROTECTED] writes:

 This is doug macEachern's bag -
 
 those who were at apachecon in london saw the progress he had made at that
 point - its pretty sweet.  check the archives for summaries of his
 presentation in late october.

Never mind the progress he made _during_ his presentation...

-- 
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star   http://www.deep-purple.com
  Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
  -

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




[ANNOUNCE] New mod_perl Web Site!!!

2000-12-05 Thread Matt Sergeant

With a flash of fireworks and champagne I'd like to announce to the world
our new mod_perl news and advocacy web site:

http://modperl.sergeant.org/

We hope to be able to bring to you all the latest relevant perl news, and
articles about mod_perl development and other areas of interest, all in
once place. We also have a copy of the mod_perl guide on the site, broken
down into sections - we hope you like this format. Eventually we will
have all the mod_perl documentation from the source POD files, and allow 
users to add comments (much like you can with the PHP documentation), and
we have much more planned for the site.

The entire site is built using AxKit and a small mod_perl handler for   
uploading news articles.

We hope you like the design, although we are aware that there are a couple
of issues with it currently:

  - We don't have O'Reilly's permission to use the eagle logo, so will
probably have to do a bit of a re-design
  - We need to find a reasonably nice way to integrate advertising onto
the site.

If you have any article or news item you would like to see published on
the site, then please visit our contribute page on the site, or drop us a
line at [EMAIL PROTECTED]

Enjoy,

The modperl.sergeant.org editing team.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




crash on connect (DBI/mysql)

2000-12-05 Thread Kraaij, Wessel


I installed the latest version of mod_perl (1.24), linked it statically to
apache 1.3.12.  (use perl 5.6). I simply want to access a MySQL database
via the DBI package (v 1.14). I installed ApacheDBI 0.87

I wrote a simple script to access a mysql database. This script works fine,
both from the command line and as a CGI script. The script stops however
at the connect call when I run it as a mod_perl module. I disabled
PerlFreshRestart, because it produced segmentation faults. I found
some similar bug reports in the mailing list archive, but found no postings
about a solution to the problem. 

Below I include the script text, and a DBI trace. Who could help? I can
supply more debug information upon request.


The script without a query string  provides a popup menu. Hitting the submit
button will actually access the database.

#!/usr/local/bin/perl
use CGI qw/:standard/;

print header,
  start_html('Database browser'),
  h1('Database browser'),
  start_form, "Which video",
 
p,popup_menu(-name='assetid',-values=['16777267','16777269','16777260']),
  submit,
  end_form,
  hr;


if (param() ) {
  print em(join (", " , param('assetid'))), hr;

$assetid = param('assetid');

use DBI;
  $Apache::DBI::DEBUG = 1;
#use strict;

DBI-trace(6,"/tmp/dbi.log");
#removed uid / pwd parameters
$dbh = DBI-connect('dbi:mysql:vip;host=', '###', '###');

$sql = "SELECT * FROM spoken_text WHERE asset_id = $assetid";
$sth = $dbh-prepare($sql);
$sth-execute || die "Could not execute SQL statement: $!\n";
while (@rows=$sth-fetchrow_array) {
print "@rows\n\n";
}

}

Here's the trace log from DBI:

  DBI 1.14-nothread dispatch trace level set to 6
Note: perl is running without the recommended perl -w option
- DBI-Apache::DBI::connect(dbi:mysql:vip;host=##, ###, )
- DBI-install_driver(mysql) for perl=5.006 pid=20105 ruid=6
euid=6
   install_driver: DBD::mysql loaded (version 2.0415)
New DBI::dr (for DBD::mysql::dr, parent=, id=)
dbih_setup_handle(DBI::dr=HASH(0x424d10)=DBI::dr=HASH(0x5c8c20),
DBD::mysql::dr, 0, Null!)
dbih_make_com(Null!, DBD::mysql::dr, 84)
dbih_setup_attrib(DBI::dr=HASH(0x5c8c20), Err, Null!) SCALAR(0x5bdcf8)
(already defined)
dbih_setup_attrib(DBI::dr=HASH(0x5c8c20), State, Null!) SCALAR(0x424fd4)
(already defined)
dbih_setup_attrib(DBI::dr=HASH(0x5c8c20), Errstr, Null!)
SCALAR(0x5bdd10) (already defined)
dbih_setup_attrib(DBI::dr=HASH(0x5c8c20), Handlers, Null!)
ARRAY(0x5c8c98) (already defined)
dbih_setup_attrib(DBI::dr=HASH(0x5c8c20), Debug, Null!) 0 (already
defined)
- install_driver= DBI::dr=HASH(0x424d10)
- FETCH= 'mysql' ('Name' from cache) at
/usr/local/lib/perl5/site_perl/5.6.0/Apache/DBI.pm line 64.
- connect for DBD::mysql::dr (DBI::dr=HASH(0x424d10)~0x5c8c20
'vip;host=#' ''  HASH(0x55c540))
New DBI::db (for DBD::mysql::db, parent=DBI::dr=HASH(0x5c8c20),
id=HASH(0x5c8c50))
dbih_setup_handle(DBI::db=HASH(0x5c8c74)=DBI::db=HASH(0x5bddc4),
DBD::mysql::db, 422d28, HASH(0x5c8c50))
dbih_make_com(DBI::dr=HASH(0x5c8c20), DBD::mysql::db, 536)
dbih_setup_attrib(DBI::db=HASH(0x5bddc4), Err, DBI::dr=HASH(0x5c8c20))
SCALAR(0x5bdcf8) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x5bddc4), State, DBI::dr=HASH(0x5c8c20))
SCALAR(0x424fd4) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x5bddc4), Errstr,
DBI::dr=HASH(0x5c8c20)) SCALAR(0x5bdd10) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x5bddc4), Handlers,
DBI::dr=HASH(0x5c8c20)) ARRAY(0x5c8c98) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x5bddc4), Debug, DBI::dr=HASH(0x5c8c20))
0 (already defined)
imp_dbh-connect: dsn = vip;host=#, uid = , pwd = #
imp_dbh-MyLogin: dbname = vip, uid = ###, pwd = #,host = ###, port
= NULL
imp_dbh-MyConnect: host = ##, port = 0, uid = , pwd = #
imp_dbh-MyConnect: client_flags = 0

The error_log from Apache shows some problems, which *could* be related to
mod_perl

[Fri Dec  1 18:47:08 2000] [crit] (13)Permission denied: make_sock: could
not bi
nd to port 80
[Fri Dec  1 18:56:06 2000] [crit] (13)Permission denied: make_sock: could
not bi
nd to port 80
[Tue Dec  5 09:42:27 2000] [crit] (13)Permission denied: make_sock: could
not bi
nd to port 80
[Tue Dec  5 09:42:31 2000] [crit] (13)Permission denied: make_sock: could
not bi
nd to port 80



 
--
Wessel Kraaij, TNO-TPD


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




ANNOUNCE: lingerd 0.91b

2000-12-05 Thread Roger Espel Llima

This is the first public release of lingerd.  You can download it
from ftp://iagora.com/pub/software/lingerd/lingerd-0.91b.tar.gz

WHAT IS LINGERD?

When an Apache process has handled a client connection, and before
it can go on to the next one, it must first wait a bit to make sure
that the other side has received all the data.  This is called
lingering_close, and is required because of some technical TCP/IP
complications.  

On a dynamic webserver with embedded scripting, and especially once
images are served separately and keep-alives are turned off,
lingering_close becomes Apache's #1 slowdown spot by a large margin.

Lingerd, then, is a daemon (service) designed to take over the job
of doing lingering_closes.  Unlike Apache, which uses one process
per connection, lingerd can do thousands of lingers in parallel,
from a single process.  This makes Apache use much fewer processes
to handle the same load.

In order to use lingerd, Apache must be patched to hand over its
network connections to the daemon.  This is done with file
descriptor passing over a Unix-domain socket, and, as the name
implies, is not very portable outside of Unix.


ARE THERE ANY ALTERNATIVES TO LINGERD?

Yes.  The "classical" solution to the lingering_close problem, and
more generally, to the problem of having a big Apache/mod_perl
process spoonfeed data to a slow client on a congested link, is to
run a front-end proxy server.  This can be done with of squid, or
with a light-weight Apache configured with mod_proxy and without any
scripting.

Lingerd removes the need for a front-end proxy server, and is much
easier to set up: no URL rewriting, no reverse rewriting rules, no
extra data copying and latency for the client.  Lingerd is also much
lighter on system resources than a proxy server.


USING IT

Lingerd is beta code.  It has only been tested under Linux (kernel
2.2.x) so far, with positive results.  The code has designed to be
robust and portable (to Unix systems anyway; I don't think it can be
ported to win32, but feel free to surprise me :)

There is also a standalone patch to Apache, that makes processes in
lingering_close visible in /server-status.  You can use this to
check if lingerd would be useful for your server.

For further instructions, read the files `README', `INSTALL' and
`testing/TESTING' in the tarball.

-- 
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: ANNOUNCE: lingerd 0.91b

2000-12-05 Thread Stas Bekman

On Tue, 5 Dec 2000, Roger Espel Llima wrote:

 This is the first public release of lingerd.  You can download it
 from ftp://iagora.com/pub/software/lingerd/lingerd-0.91b.tar.gz
 
 WHAT IS LINGERD?
 
 When an Apache process has handled a client connection, and before
 it can go on to the next one, it must first wait a bit to make sure
 that the other side has received all the data.  This is called
 lingering_close, and is required because of some technical TCP/IP
 complications.  
 
 On a dynamic webserver with embedded scripting, and especially once
 images are served separately and keep-alives are turned off,
 lingering_close becomes Apache's #1 slowdown spot by a large margin.
 
 Lingerd, then, is a daemon (service) designed to take over the job
 of doing lingering_closes.  Unlike Apache, which uses one process
 per connection, lingerd can do thousands of lingers in parallel,
 from a single process.  This makes Apache use much fewer processes
 to handle the same load.

Very cool!

Any benchmarks? The theoretical explanation, is quite good for those who
understand the problem, but far from being convincing for those who don't.

Also I suppose that you must say that Lingerd becomes the new Achilles
heel, since if this daemon goes down the whole server won't work.

 ARE THERE ANY ALTERNATIVES TO LINGERD?
 
 Yes.  The "classical" solution to the lingering_close problem, and
 more generally, to the problem of having a big Apache/mod_perl
 process spoonfeed data to a slow client on a congested link, is to
 run a front-end proxy server.  This can be done with of squid, or
 with a light-weight Apache configured with mod_proxy and without any
 scripting.
 
 Lingerd removes the need for a front-end proxy server, and is much
 easier to set up: no URL rewriting, no reverse rewriting rules, no
 extra data copying and latency for the client.  Lingerd is also much
 lighter on system resources than a proxy server.

May I suggest a correction here? "It removes the need for a front-end
proxy server only if you needed it in first place to solve the downstream
client feeding problem."


_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: crash on connect (DBI/mysql)

2000-12-05 Thread Stas Bekman

[DBI script problem skipped]

 The error_log from Apache shows some problems, which *could* be related to
 mod_perl
 
 [Fri Dec  1 18:47:08 2000] [crit] (13)Permission denied: make_sock: could
 not bi
 nd to port 80
 [Fri Dec  1 18:56:06 2000] [crit] (13)Permission denied: make_sock: could
 not bi
 nd to port 80
 [Tue Dec  5 09:42:27 2000] [crit] (13)Permission denied: make_sock: could
 not bi
 nd to port 80
 [Tue Dec  5 09:42:31 2000] [crit] (13)Permission denied: make_sock: could
 not bi
 nd to port 80

Uhm, before we try to solve the problem in hand, I don't understand your
statement of Apache showing *some* problems. What port are you running
mod_perl server at? 80? do you run a single mod_perl server or is there a
front-end server?

Second, you should make your code more debug friendly. Replace:
$dbh = DBI-connect('dbi:mysql:vip;host=', '###', '###');
with
$dbh = DBI-connect('dbi:mysql:vip;host=', '###', '###') 
or die $DBI::errstr;

what error do you get? You don't really need to trace to get the reason of
why the connect call fails.

(BTW, die $DBI::errstr; is in the DBI manpage)

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Response time of a perl script!!!

2000-12-05 Thread Edmar Edilton da Silva

Hi folks,

I ran a same perl script twice. First time only under mod_perl,
and after under mod_perl and Apache::DBI. The response time of both
experiments was very different. The last was fastest than the first
approximately 20 times. Is it correctly? If the response time of a perl
script with mod_perl is bad, I think that it without mod_perl will be
much worse. I also would like to know if when the apache (with mod_perl)
starts each child process already has one embedded interpreter or they
will have only when the first request arrives. Please, if soneone help me
will be very appreciated. Thanks...

Edmar,  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: [ANNOUNCE] New mod_perl Web Site!!!

2000-12-05 Thread Oleg Bartunov

Matt,

I know you like modern technologies but your site doesn't like
my browser (NS 3.0, Solaris). I got blank screen with 2 popup
windows with message "/bin/sh: gzip: not found"
Hope you know what does it mean :-)

Regards,

Oleg
On Tue, 5 Dec 2000, Matt Sergeant wrote:

 Date: Tue, 05 Dec 2000 10:42:20 +
 From: Matt Sergeant [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: [ANNOUNCE] New mod_perl Web Site!!!
 
 With a flash of fireworks and champagne I'd like to announce to the world
 our new mod_perl news and advocacy web site:
 
 http://modperl.sergeant.org/
 
 We hope to be able to bring to you all the latest relevant perl news, and
 articles about mod_perl development and other areas of interest, all in
 once place. We also have a copy of the mod_perl guide on the site, broken
 down into sections - we hope you like this format. Eventually we will
 have all the mod_perl documentation from the source POD files, and allow 
 users to add comments (much like you can with the PHP documentation), and
 we have much more planned for the site.
 
 The entire site is built using AxKit and a small mod_perl handler for   
 uploading news articles.
 
 We hope you like the design, although we are aware that there are a couple
 of issues with it currently:
 
   - We don't have O'Reilly's permission to use the eagle logo, so will
 probably have to do a bit of a re-design
   - We need to find a reasonably nice way to integrate advertising onto
 the site.
 
 If you have any article or news item you would like to see published on
 the site, then please visit our contribute page on the site, or drop us a
 line at [EMAIL PROTECTED]
 
 Enjoy,
 
 The modperl.sergeant.org editing team.
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl with threaded Apache (eg Apache2)

2000-12-05 Thread Stas Bekman

 Is anyone working on an upgrade to mod_perl to
 handle Apache 2.0b with thread support?

I think some guy who's name is Doug is working on it :)
But seriously take a look at:
http://perl.apache.org/~dougm/modperl_2.0.html

 If so, do you want my help?

Yes. 

Join the cvs mailing list (See http://perl.apache.org/#dev-list), 

Get the source http://perl.apache.org/from-cvs/modperl-2.0/ or
http://perl.apache.org/mod_perl_cvs.html and see what was done already.

Basically the plan set by Doug is this: 

Step 1: Doug, the main architect to start and complete the new skeleton of
the ship. Some occasional snowboarding to get the inspiration.

Step 2: The crowd of skilled carpenters to start working on the deck
and masts. Chefs to take over the kitchen. Doug to go snowboarding
fulltime.

Step 3: Rule the world and spend all the time snowboarding.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Response time of a perl script!!!

2000-12-05 Thread Stas Bekman

   I ran a same perl script twice. First time only under mod_perl,
 and after under mod_perl and Apache::DBI. The response time of both
 experiments was very different. The last was fastest than the first
 approximately 20 times. Is it correctly? If the response time of a perl
 script with mod_perl is bad, I think that it without mod_perl will be
 much worse. I also would like to know if when the apache (with mod_perl)
 starts each child process already has one embedded interpreter or they
 will have only when the first request arrives. Please, if soneone help me
 will be very appreciated. Thanks...

Edmar Edilton, I suggest that you read the documentation first. We'd
gladly answer your questions that aren't coverted by documentation. I've
already responded your exact question with link to
http://perl.apache.org/guide/, have you read it and still have this
question?


_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RFC: mod_perl Guide 2.0

2000-12-05 Thread Stas Bekman

Since we have already started working on mod_perl-2.0, I wanted to get in
early and provide the base for the one and only source of mod_perl
documentation. These are the things that I see important:

1. *All* pods located under one roof. API, Installation, Configuration,
Tips, Trick and more. 

2. Automatic retrieval of pods sections from .pm files and integration in
the documentation tree.

3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
already working in the guide, other formats to come).

4. Distribution within mod_perl or outside of it? (The main point of
having documentation separated as it may be updated more often than
software releases.) so this is arguable.

5. Commit rights. Should be available for all mod_perl committers, one or
more persons will be responsible for keeping the healthy layout of the
documentation, review documentation commits. Pretty much making it a
real community project and not Stas Bekman's project.

6. Mailing list (or reuse of cvs list) for corrections/contributions

7. The relevant parts from the current guide is to be merged into the new
guide and eventually freezed as mod_perl-2.0 will become the main product,
and mod_perl-1.x will be not supported anymore (I suppose a few years from
now).

Comments are welcome.

Once Doug gets back, given his approval we will start to layout the
documentation infrastructure in the cvs tree.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl Guide 2.0

2000-12-05 Thread Matt Sergeant

On Tue, 5 Dec 2000, Stas Bekman wrote:

 Since we have already started working on mod_perl-2.0, I wanted to get in
 early and provide the base for the one and only source of mod_perl
 documentation. These are the things that I see important:

 1. *All* pods located under one roof. API, Installation, Configuration,
 Tips, Trick and more.

Is the guide the best place for tips and tricks? Its certainly the best
place for hard-core installation configuration and other stuff, but often
tips and tricks focus on one particular technology. Are we missing out on
having a place to store smaller tips and tricks (you know where I'm
thinking of keeping them...) ?

 2. Automatic retrieval of pods sections from .pm files and integration in
 the documentation tree.

Is that really necessary? I assume you mean having the Apache.pm docs as
part of the guide, and the mod_perl*.pod files also?

 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
 already working in the guide, other formats to come).

What other formats do you think people want/need?

 4. Distribution within mod_perl or outside of it? (The main point of
 having documentation separated as it may be updated more often than
 software releases.) so this is arguable.

Yes, keep it out of mod_perl. We all love doug but he's slower than a very
slow thing on a Sunday :-)

 5. Commit rights. Should be available for all mod_perl committers, one or
 more persons will be responsible for keeping the healthy layout of the
 documentation, review documentation commits. Pretty much making it a
 real community project and not Stas Bekman's project.

/me spies the ulterior motive behind that :-)

 6. Mailing list (or reuse of cvs list) for corrections/contributions

Is there anything wrong with using this list for that?

 7. The relevant parts from the current guide is to be merged into the new
 guide and eventually freezed as mod_perl-2.0 will become the main product,
 and mod_perl-1.x will be not supported anymore (I suppose a few years from
 now).

We probably need to keep two separate projects, going on what is known
about mod_perl 2.0 so far.

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl Guide 2.0

2000-12-05 Thread Salve J Nilsen

Suddenly, Stas Bekman uttered:

 Since we have already started working on mod_perl-2.0, I wanted to get in
 early and provide the base for the one and only source of mod_perl
 documentation. These are the things that I see important:

 2. Automatic retrieval of pods sections from .pm files and integration in
 the documentation tree.

That would be nice! :)

 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
 already working in the guide, other formats to come).

I'd _very_much_ like a PDA-version of the guide! It might have to be
set up differently (e.g. code snippets presented with fixed a width
font should go into seperate files, and deep nesting of lists should
be avoided (max. 2 levels?)). Lots of UI improvements could probably
be made... :)

The guide as it is, isn't much readable on my iPaq, at least. :(

 4. Distribution within mod_perl or outside of it? (The main point of
 having documentation separated as it may be updated more often than
 software releases.) so this is arguable.

Outside, and perhaps set mod_perl to require the documentation to be
installed? (which might make installation via CPAN.pm a little easier
:)

 6. Mailing list (or reuse of cvs list) for corrections/contributions

Don't we have enough mailing lists? :)



- Salve

-- 
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};{'";@_=unpack("C*",unpack("u*",':4@,$'.# [EMAIL PROTECTED]
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "{'@_'}";   __END__ is near! :)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl Guide 2.0

2000-12-05 Thread Matt Sergeant

On Tue, 5 Dec 2000, Salve J Nilsen wrote:

  3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
  already working in the guide, other formats to come).

 I'd _very_much_ like a PDA-version of the guide! It might have to be
 set up differently (e.g. code snippets presented with fixed a width
 font should go into seperate files, and deep nesting of lists should
 be avoided (max. 2 levels?)). Lots of UI improvements could probably
 be made... :)

 The guide as it is, isn't much readable on my iPaq, at least. :(

What's the format the iPaq can read? Isn't it an XML format?

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl Guide 2.0

2000-12-05 Thread Salve J Nilsen

Suddenly, Matt Sergeant uttered:
 On Tue, 5 Dec 2000, Salve J Nilsen wrote:

   3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
   already working in the guide, other formats to come).
 
  I'd _very_much_ like a PDA-version of the guide! It might have to be
  set up differently (e.g. code snippets presented with fixed a width
  font should go into seperate files, and deep nesting of lists should
  be avoided (max. 2 levels?)). Lots of UI improvements could probably
  be made... :)
 
  The guide as it is, isn't much readable on my iPaq, at least. :(

 What's the format the iPaq can read? Isn't it an XML format?

HTML. There are two ways (AFAIK) to get web pages onto the iPaq: the
first is to use the "Mobile Favourites" feature in IE (Windows
PocketPC comes with a tiny version of IE), and the other way is by
using AvantGo, which might be looked upon as an IE application for
syncronizing web pages.

So actually, the format is HTML (dunno which versions Pocket IE can
handle, though. Maybe XHTML1.0 works? :)

I'd love to find out what might work, but it'll have to wait until
this weekend :)


- Salve

-- 
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};{'";@_=unpack("C*",unpack("u*",':4@,$'.# [EMAIL PROTECTED]
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "{'@_'}";   __END__ is near! :)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl Guide 2.0

2000-12-05 Thread Stas Bekman

On Tue, 5 Dec 2000, Matt Sergeant wrote:

 On Tue, 5 Dec 2000, Stas Bekman wrote:
 
  Since we have already started working on mod_perl-2.0, I wanted to get in
  early and provide the base for the one and only source of mod_perl
  documentation. These are the things that I see important:
 
  1. *All* pods located under one roof. API, Installation, Configuration,
  Tips, Trick and more.
 
 Is the guide the best place for tips and tricks? Its certainly the best
 place for hard-core installation configuration and other stuff, but often
 tips and tricks focus on one particular technology. Are we missing out on
 having a place to store smaller tips and tricks (you know where I'm
 thinking of keeping them...) ?

You can always reproduce them at will, I'm advocating the one and only
source. There is too much confusion with the way things are
now. Especially for newbies.

  2. Automatic retrieval of pods sections from .pm files and integration in
  the documentation tree.
 
 Is that really necessary? I assume you mean having the Apache.pm docs as
 part of the guide, and the mod_perl*.pod files also?

Absolutely, the current guide has lots of things duplicated with Apache.pm
docs and the mod_perl*.pod, because it tries to be complete (well the only
thing it doesn't attempt to cover is API). All we need is a well-thought
layout that will make the use and maintenance easy.

  3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
  already working in the guide, other formats to come).
 
 What other formats do you think people want/need?

I don't know. Just trying to keep things open. As suggested in another
reply WAP formats (or the new ones replacing WAP)

  5. Commit rights. Should be available for all mod_perl committers, one or
  more persons will be responsible for keeping the healthy layout of the
  documentation, review documentation commits. Pretty much making it a
  real community project and not Stas Bekman's project.
 
 /me spies the ulterior motive behind that :-)

No motives, it's too good to be Stas Bekman :) Others should be able to
join, and contribute more, without having my shade over their head.

  6. Mailing list (or reuse of cvs list) for corrections/contributions
 
 Is there anything wrong with using this list for that?

Yes, you don't see all the corrections that I receive in my personal
email. There are quite many of them at times. It'll create unneccesary
traffic for those who aren't interested in these corrections. Believe me I
know what I'm saying here :)

Another item that I've forgotten about, is someone who watches the list
(it was me until now and it's still me) and pickes new problems and their
solutions, new technological tips and tricks and other important stuff
that need to end up in the documentation and not only in the list
archives. Geoff is doing a great job providing the summaries, but someone
is to write down the real details.

  7. The relevant parts from the current guide is to be merged into the new
  guide and eventually freezed as mod_perl-2.0 will become the main product,
  and mod_perl-1.x will be not supported anymore (I suppose a few years from
  now).
 
 We probably need to keep two separate projects, going on what is known
 about mod_perl 2.0 so far.

Sure, as I said the 1.x will not die in the next few years. So once
mod_perl 2.0 goes live, /guide will point to the new guide and /guide-1.x
will have the old guide available.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: [ANNOUNCE] New mod_perl Web Site!!!

2000-12-05 Thread G.W. Haywood

Hi all,

On Tue, 5 Dec 2000, Oleg Bartunov wrote:

 (NS 3.0, Solaris). I got blank screen with 2 popup
 windows with message "/bin/sh: gzip: not found"

Well you can't say I didn't warn you...

73,
Ged.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Matt Sergeant

On Tue, 5 Dec 2000, Stas Bekman wrote:

 I see two main streams:
 1) Online zines.

 I think that we should start working on locating ezines wanting to publish
 mod_perl related articles (preferrably for a fee, to give incentives for
 others to write)

While I can't offer any money for articles (unless someone out there wants
to sponsor the site!), hopefully if anyone has an itch to write about
something they'll go along to http://modperl.sergeant.org/contribute.xml
and drop us a note.

However I'd also really like to see more in offline publications. For
example, I've never read anything in Web Techniques, other than a Lincoln
or a Merlyn article, go into detail about mod_perl, or even just review
it, or review some system built on mod_perl (like Mason or Embperl for
example) [*]. I have, however, seen reviews of Velocigen, which often cite
mod_perl as a competitor and as difficult to install, and therefore bad
(note that I do think mod_perl is still a tad too hard to install for
complete newbies, but its a specious argument because you tend to only do
it once or twice, and thats something not many documents focus on).

[*] Actually this is a lie, I've seen an article about Mason in WT, but
I'd like to see more.

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Stas Bekman

Well as you've probably figured out, based on the load of email from me,
I've dropped my last job, in order to finally finish the mod_perl book,
have some rest and make a push to mod_perl.

Yesterday I've updated the stats page:
http://perl.apache.org/netcraft/ and the results are so-so, we go down on
the number of domains. Which I suppose mainly caused by people reading the
guide and deploying the front-end proxy solution, thus making mod_perl
un-seen by various scanners like netcraft.

In Paris we couldn't hire a single mod_perl programmer, because people
don't even know what that. They know a lot about php and ASP. It's true
that they don't even know what's Perl :(

But, you all know that php pretty much takes over. Why? For two reasons:
1) initial corporate pushing (press/ads) 
2) once well known, the word of the mouth does the rest.

mod_perl lucks the corporate money/PR to get pushed. But we can still work
on the exposure, which will bring corporate money/PR thru the word of the
mouth.

Luckily Matt has got sick of waiting for someone to work on the advocacy
of mod_perl and he has just taken over it. Having a good informational
site is good, but it's not enough. We need to solve the problem of people
to find this site and wanting to use mod_perl. Solution? Spreading the
word.

I see two main streams:
1) Online zines.
2) Conferences.

I think that we should start working on locating ezines wanting to publish
mod_perl related articles (preferrably for a fee, to give incentives for
others to write) and conferences where mod_perl can be relevant. The data
is to be collected and distributed to the people who wish to advocate
mod_perl, thru written articles and conference classes. I suppose that we
will also look for companies who want to order mod_perl classes and find
the teachers in the appropriate areas.

May be we could organize some certification classes, to give more PR to
mod_perl.

I suppose that much more can be done. Comments are welcome.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: ANNOUNCE: lingerd 0.91b

2000-12-05 Thread Roger Espel Llima

Stas Bekman [EMAIL PROTECTED] wrote:
 Very cool!
 Any benchmarks? The theoretical explanation, is quite good for those who
 understand the problem, but far from being convincing for those who don't.

Yep.  Benchmarking with a copy of 'ab' modified to keep the client
sockets open for a while (like NS and IE do), doing 12 concurrent
requests on a slow dynamic Apache/mod_perl page, I get:

* without lingerd: number of Apache processes grows from 10 to 39,
  with a peak at 43.  Load average reaches 14.

* with lingerd: number of Apache processes grows from 10 to 20, with
  a peak at 22.  Load average reaches 10.

The speed of the server improved slightly (from 17 to 20 pages per
second), probably because of the lessened memory and scheduling
pressure.  

With only 6 concurrent requests, the speed stayed exactly the same
with or without lingerd, but the number of servers went from 27 to
12.

 Also I suppose that you must say that Lingerd becomes the new Achilles
 heel, since if this daemon goes down the whole server won't work.

By default, if Apache can't find lingerd, it will do the lingering
itself, the usual (slow) way.

If you come to depend on the extra scalability that lingerd brings,
you can configure Apache to not do lingering_close at all if lingerd
fails.  It sucks, but it's better to having the server fall over
with the load...  then again, that's what MaxClients is for.

 May I suggest a correction here? "It removes the need for a front-end
 proxy server only if you needed it in first place to solve the downstream
 client feeding problem."

Yep, you're right :)  

A proxy front-end can also serve images and do load-balancing.  In
the `README' for lingerd I suggest using thttpd and Piranha for each
of these, but it's true that mod_proxy or mod_rewrite works too.

-- 
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread kevin montuori

 Stas Bekman writes:

  sb Luckily Matt has got sick of waiting for someone to work on the
  sb advocacy of mod_perl and he has just taken over it. Having a
  sb good informational site is good, but it's not enough. We need to
  sb solve the problem of people to find this site and wanting to use
  sb mod_perl. Solution? Spreading the word.
  
  i agree with what SB says, spreading the word is of primary
  importance.  

  additionally, i think that some consideration should be given to
  how mod_perl is packaged.  although it's well documented (and
  generally quite simple) there are three kits that need to be
  compiled (apache, perl, mod_perl) before the simplest handler
  can be tested.  i think to an applications programmer who's
  perhaps written a few CGI scripts, setting up the infrastructure
  necessary to run mod_perl is a bit daunting, particularly if it
  also involves mod_ssl.

  this is the biggest complaint i've heard from new users, and i'm
  not certain that i have any viable solutions to offer; after
  all, there's gobs of documentation already, thanks to the guide.
  perhaps bundling the various components together and driving the
  configuration/build from a single script?  i don't know.

  cheers,
  k.

-- 
kevin montuori

support independent booksellers -- http://www.booksense.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread Michael Nachbaur

I would tend to agree with this on several points, but I have a few things to add (I 
didn't want this to be a "Me Too!" post.)

A lot of the mindshare for this space has been taken over by Java.  While some of you 
out there have actually tried to implement something in Java, then ran screaming back 
to Perl with your hair on fire, others aren't so "Lucky".  I've been researching 
ecommerce and content management solutions for my company (take a guess who), and the 
Java technologies are *filled* with marketing hype that makes all the business users 
drool.  I almost bought into it completely.

I don't want to suggest that the Perl community should stoop as low as Java, but they 
have a very good thing going for them.  They're presenting their data (very very 
skewed data, but data nontheless) in a very whizz-bang fashion, saying all the right 
words like "Inheritance", "Encapsulation", and bunches of other things that the 
marketroids gloss over at and think "Wow, this must be great stuff if I can't 
understand it!".  What do we say with perl?  "Scripting language", "Package", 
"Subroutine", "Array" and "Hash".  While we can do almost everything that Java can do 
(we can, can't we?), we can do it a whole lot faster, in an easy-to-code fashion.  

I don't know what I'm getting at here, but I see that Perl is half a step behind Java 
in many ways, except for the performance issues (which perl is leagues ahead).  For my 
company, we're probably going Java, but it sorta makes sense for us (we need an 
enterprise solution now...not when the Perl community gets around to it).

Thanks for listening to my rant, and good hunting everyone!

-man
Michael A Nachbaur
mike(at)nachbaur(dot)com
http://www.nachbaur.com

-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 05, 2000 6:50 AM
To: mod_perl list
Subject: RFC: mod_perl advocacy project resurrection


Well as you've probably figured out, based on the load of email from me,
I've dropped my last job, in order to finally finish the mod_perl book,
have some rest and make a push to mod_perl.

Yesterday I've updated the stats page:
http://perl.apache.org/netcraft/ and the results are so-so, we go down on
the number of domains. Which I suppose mainly caused by people reading the
guide and deploying the front-end proxy solution, thus making mod_perl
un-seen by various scanners like netcraft.

In Paris we couldn't hire a single mod_perl programmer, because people
don't even know what that. They know a lot about php and ASP. It's true
that they don't even know what's Perl :(

But, you all know that php pretty much takes over. Why? For two reasons:
1) initial corporate pushing (press/ads) 
2) once well known, the word of the mouth does the rest.

mod_perl lucks the corporate money/PR to get pushed. But we can still work
on the exposure, which will bring corporate money/PR thru the word of the
mouth.

Luckily Matt has got sick of waiting for someone to work on the advocacy
of mod_perl and he has just taken over it. Having a good informational
site is good, but it's not enough. We need to solve the problem of people
to find this site and wanting to use mod_perl. Solution? Spreading the
word.

I see two main streams:
1) Online zines.
2) Conferences.

I think that we should start working on locating ezines wanting to publish
mod_perl related articles (preferrably for a fee, to give incentives for
others to write) and conferences where mod_perl can be relevant. The data
is to be collected and distributed to the people who wish to advocate
mod_perl, thru written articles and conference classes. I suppose that we
will also look for companies who want to order mod_perl classes and find
the teachers in the appropriate areas.

May be we could organize some certification classes, to give more PR to
mod_perl.

I suppose that much more can be done. Comments are welcome.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Gunther Birznieks

At 03:49 PM 12/5/00 +0100, Stas Bekman wrote:
Well as you've probably figured out, based on the load of email from me,
I've dropped my last job, in order to finally finish the mod_perl book,
have some rest and make a push to mod_perl.

Yesterday I've updated the stats page:
http://perl.apache.org/netcraft/ and the results are so-so, we go down on
the number of domains. Which I suppose mainly caused by people reading the
guide and deploying the front-end proxy solution, thus making mod_perl
un-seen by various scanners like netcraft.

In Paris we couldn't hire a single mod_perl programmer, because people
don't even know what that. They know a lot about php and ASP. It's true
that they don't even know what's Perl :(

But, you all know that php pretty much takes over. Why? For two reasons:
1) initial corporate pushing (press/ads)
2) once well known, the word of the mouth does the rest.

Is this really what it is? I guess I must be ignoring the PHP ads cuz I 
dont see THAT many.

I think #1 is a little odd because I think Perl has gotten a lot of press 
and advertisement compared to PHP. Mod_perl is really just a technology on 
top of Perl then.

I think someone mentioned that the PHP website was quite rich with recipes 
and links to applications written to work with PHP. If people knew there 
was an open source source of apps for mod_perl, they'd probably be more 
inclined to use it because then mod_perl wouldn't be about being forced to 
develop an app from scratch.

mod_perl lucks the corporate money/PR to get pushed. But we can still work
on the exposure, which will bring corporate money/PR thru the word of the
mouth.

Perhaps Covalent could sponsor an ad in a large computer magazine. I am not 
sure that would help necessarily though.

Luckily Matt has got sick of waiting for someone to work on the advocacy
of mod_perl and he has just taken over it. Having a good informational
site is good, but it's not enough. We need to solve the problem of people
to find this site and wanting to use mod_perl. Solution? Spreading the
word.

I think provided Matt gets the articles, that will go a long way. I'm busy 
working on my submission about using CGI::Carp and mod_perl. (Just kidding 
about the subject matter Matt).

I see two main streams:
1) Online zines.
2) Conferences.

I think that we should start working on locating ezines wanting to publish
mod_perl related articles (preferrably for a fee, to give incentives for
others to write) and conferences where mod_perl can be relevant. The data
is to be collected and distributed to the people who wish to advocate
mod_perl, thru written articles and conference classes. I suppose that we
will also look for companies who want to order mod_perl classes and find
the teachers in the appropriate areas.

May be we could organize some certification classes, to give more PR to
mod_perl.

Maybe Randal's company (which I *think* specializes in training among other 
things) could help in that area -- the idea of mod_perl certification is 
more intriguing I think than just plain perl certification.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread Wiswell, Virginia


 with your hair on fire, others aren't so "Lucky".  I've been 
 researching ecommerce and content management solutions for my 
 company (take a guess who), and the Java technologies are 
 *filled* with marketing hype that makes all the business 
 users drool.  I almost bought into it completely.
 
 I don't want to suggest that the Perl community should stoop 
 as low as Java, but they have a very good thing going for 
 them.  They're presenting their data (very very skewed data, 
 but data nontheless) in a very whizz-bang fashion, saying all 
 the right words like "Inheritance", "Encapsulation", and 
 bunches of other things that the marketroids gloss over at 
 and think "Wow, this must be great stuff if I can't 
 understand it!".  What do we say with perl?  "Scripting 
 language", "Package", "Subroutine", "Array" and "Hash".  
 While we can do almost everything that Java can do (we can, 
 can't we?), we can do it a whole lot faster, in an 
 easy-to-code fashion.  

sounds like we need a 'hacketer': hacker/marketer. any hackers out there
with MBA's or is that an oxymoron?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl Guide 2.0

2000-12-05 Thread Jorge Godoy

On Tue, 5 Dec 2000, [EMAIL PROTECTED] wrote:

 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf
 are already working in the guide, other formats to come).
 
 What other formats do you think people want/need?

info files would be cool. :-) 



See you,
-- 
Godoy. [EMAIL PROTECTED]

Departamento de Publicações   Conectiva S.A.
Publishing Department Conectiva Inc.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread martin langhoff

kevin montuori wrote:

   additionally, i think that some consideration should be given to
   how mod_perl is packaged. 


I think it's of crucial importance the fact that a distro as widespread
as RHLinux 6.x had mod_perl messed up. That has forced quite a lot of
developers that were trying to get their feet wet with mod_perl to get
in a complex compile sequence. That's a source of 'bad reputation', and
of php developers, as the included php was old but working ;)

I don't know how messed up are other distros regarding apache/mod_perl,
but making sure the main distros *do* get it right is paramount to make
mod_perl catch. 

Another item that we should really have is a good (and somehow
sanctioned) RPM that replaces the apache rpm (or deb) included in broken
distros. Then we can include in the guide and related pages a link for
[broken-distro-name] users, so they get a suitable replacement with a
similar config. That's an important issue, because a redhat user has
other non-standard modules included in his rpm, such as PHP, and
compiling a *complete* apache, with mod_perl, php and the kitchen sink
is a daunting task -- and too high an entry price. 

anyway, not an easy task ... mmhhh..



martin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread JoshNarins


It'd be nice if there was an equivalent of info's "h"...

i.e., an "I've got Linux, what next?" track

That might seriously encourage more hobbyists =+
more open source community

(is there a way to indicate that the operator
should be read backwards?)



Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread David Hodgkinson

kevin montuori [EMAIL PROTECTED] writes:

   additionally, i think that some consideration should be given to
   how mod_perl is packaged.  although it's well documented (and
   generally quite simple) there are three kits that need to be
   compiled (apache, perl, mod_perl) before the simplest handler
   can be tested.  i think to an applications programmer who's
   perhaps written a few CGI scripts, setting up the infrastructure
   necessary to run mod_perl is a bit daunting, particularly if it
   also involves mod_ssl.

Is the RH7.0 installation stable? It comes with everything as a DSO
and _should_ work...



-- 
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star   http://www.deep-purple.com
  Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
  -

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread J. J. Horner

On Tue, Dec 05, 2000 at 11:46:38PM +0800, Gunther Birznieks wrote:
 Maybe Randal's company (which I *think* specializes in training among other 
 things) could help in that area -- the idea of mod_perl certification is 
 more intriguing I think than just plain perl certification.
 
 

Now this is something I would like.  I am not big on certs (I don't have a single
one), but if I were to get one, this would be it.  I like mod_perl, and although
I have only really started writing one public mod_perl module (anyone remember
Apache-AuthExpire?  Didn't think so, browser differences killed it), and I've
written numerous custom stuff for work (sorry can't go into detail), I'm light
on content handlers.  I'm more backend, since I am not the most creative knife
in the box.

If I could get certified with mod_perl from [merlyn] and have the certification
jive with the creators, it would help me considerably when I market myself as 
a hired-gun mod_perl coder.

And we all remember the M$ scheme of an army of papered drones chanting "Microsoft
is great!".  We all now that it sold M$ software more than the software really did.

If we can get an elite force of mod_perl hackers on the scene to spread the gospel,
we would see a big boon to mod_perl press and support.

Just my unlearned $0.02.

JJ
-- 
J. J. Horner
[EMAIL PROTECTED]

"The people who vote decide nothing.
The people who count the vote decide everything."
- Josef Stalin

"The tree of liberty must be watered periodically with the 
blood of tyrants and patriots alike. ... Resistance to tyrants
is obedience to God."
- Thomas Jefferson

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread Wiswell, Virginia

how about creating partnerships with companies (o'reilly, red hat, va linux,
etc.)? i get email all the time promoting products and if one sounds
interesting, i usually follow the link to check it out, especially if it's
free and will help me do my job faster and/or better. some press releases to
zdnet and some of the other main stream technical sites might get the name
out there. probably the first thing to decide is who the target audience is
and go from there.

just some thoughts and distraction from the daily ho-hum.

virginia

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Paul


--- Stas Bekman [EMAIL PROTECTED] wrote:
.
 I see two main streams:
 1) Online zines.
 2) Conferences.

Apache.org has a whole subsection devoted to mod_perl
Any idea what it would take to get a link there from webs like tpj and
Perl.com?  I was thinking that perl.com has a nice series of articles
going for newcomers to the language, and Mark Jason-Dominus' series of
red-flag articles has certainly been worth a read; wouldn't a less
generic article series for less-new users interested in perl topics
like Apache be worth space and a link?  I've seen links to specific
high-profile uses like the Human Genome Project as Perl advocacy.
Wouldn't mod_perl be worth an ongoing link page in that right, perhaps
with discussions of sites handling thorny problems?  Or am I behind the
times on that one?

I'd even volunteer to write a few articles, though I hardly consider
myself qualified to teach anything more than the basic concepts.  I'm
still on the steep side of the learning curve for designing effective
and efficient subsites with handlers and some Embperl, but our shop has
some odd needs that mod_perl seems built-for, and I do love to talk

comments?

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Rufus . Cable

Has anyone tried the Apache Toolbox script at www.apachetoolbox.com ? It's
supposed to configure and build Apache and a large number of modules without
all the manual configuration. The script is zipped to about 16k - you just
downloda that and it's smart enough to fetch the tarballs for each package
you've selected if they're not already there.

I've only just downloaded it, and so far its pretty menu is confusing my
poor terminal program, but it looks like it could ease the pain (especially
the trial-and-error bit - admittedly unnecessary if you read the docs
*first*! :) ) of the usual config procedures... The author also mentions
plans to port it to Perl!

Rufus.

-Original Message-
From: kevin montuori [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 05, 2000 3:51 PM
To: [EMAIL PROTECTED]
Subject: Re: RFC: mod_perl advocacy project resurrection


 Stas Bekman writes:

  sb Luckily Matt has got sick of waiting for someone to work on the
  sb advocacy of mod_perl and he has just taken over it. Having a
  sb good informational site is good, but it's not enough. We need to
  sb solve the problem of people to find this site and wanting to use
  sb mod_perl. Solution? Spreading the word.
  
  i agree with what SB says, spreading the word is of primary
  importance.  

  additionally, i think that some consideration should be given to
  how mod_perl is packaged.  although it's well documented (and
  generally quite simple) there are three kits that need to be
  compiled (apache, perl, mod_perl) before the simplest handler
  can be tested.  i think to an applications programmer who's
  perhaps written a few CGI scripts, setting up the infrastructure
  necessary to run mod_perl is a bit daunting, particularly if it
  also involves mod_ssl.

  this is the biggest complaint i've heard from new users, and i'm
  not certain that i have any viable solutions to offer; after
  all, there's gobs of documentation already, thanks to the guide.
  perhaps bundling the various components together and driving the
  configuration/build from a single script?  i don't know.

  cheers,
  k.

-- 
kevin montuori

support independent booksellers -- http://www.booksense.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread kevin montuori

 David Hodgkinson writes:


  dh Is the RH7.0 installation stable? It comes with everything as a
  dh DSO and _should_ work...

  hmmm, if i could get RH7.0 to *install* i could check that out.
  anaconda (read: python) can't find it's POSIX libs, so the whole 
  thing's a bust from the get-go.  (i'm a bit bitter about RH 7.)

  prebuilt solves the problem nicely for people running linux;
  however, that's not everybody.  i'm sure there are sun shops out
  there without the sysadmin expertise to download and compile
  mod_perl properly.  i'd rather see the configure/compile process
  simplified than try to provide binaries for a dozen platforms --
  that would allow the folks who'd be tied to compiling each new
  release to do more interesting and profitable things.

  i'm also sure that there are "technical managers" who can be
  sold on Perl, since it's from a single source, but cannot be
  convinced that running an enterprise system on software that's
  been culled from three separate sources will prove robust.  i
  know it works, you know it works, but people who'd accept a job
  title like "technical manager" might get nervous.  

  personally, i have no issues with how it works now; i'm just
  trying to contribute what i've heard the problems are.

  cheers,
  k.

-- 
kevin montuori

support independent booksellers -- http://www.booksense.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread brian moseley

On Tue, 5 Dec 2000, Stas Bekman wrote:

 But, you all know that php pretty much takes over. Why? For two reasons:
 1) initial corporate pushing (press/ads) 
 2) once well known, the word of the mouth does the rest.

oh, there's also the part about php being so much easier to
setup and to program ;)

if you really feel the need to compete with php in the
lowest tier web app space, you need to make simplicity your
#1 goal. php is awesome entry level technology, and i almost
always recommend it over perl to people who only have the
desire to do casual programming for personal sites and small
projects. and that's a significant percentage of the people
i know doing web programming.

i'd love to see us evolve mod_perl with simplicity and ease
of use in mind. but precisely because php exists, i think
there's a more important goal for us: creating
infrastructure that can get perl accepted by the pointy
heads in the engineering shops and corporate it depts.
competing with java, rather than php.

java's got 2 things perl doesn't: a huge, well funded
marketing machine, and a large set of standard apis *that
were designed to work together* which have almost universal
programmer acceptance. i know it's heresy, but while
tmtowtdi is a cute slogan, it doesn't market us well outside
the circle of perl programmers.

how many of you have tried to hire engineers with
significant mod_perl experience? it's almost impossible,
even in san francisco which is supposed to be the wellspring
of geekery. 5 out of 10 perl programmers i interview have
not used mod_perl; 4 of the rest have only ever used
registry; and the last guy has an equal shot at having
experience with embperl, mason or his own homegrown
presentation layer. there is almost no talent pool with a
consistent skill set. makes it really difficult as a manager
to want to continue with a mod_perl-based application when
senior engineers who love java are more or less a dime a
dozen.

we need to create standards for ourselves and fully embrace
them. DBI is a great example. the explosion of mod_perl
presentation technologies is a great counter example.

we need to achieve significant vendor support, in the
development tools area, the enterprise software area, the
content management area, etc. how many of you use rational
rose for analysis  design? how many of you would use it for
code maintenance as well if it could round trip engineer
perl?

a premise of the perl philosophy is that it's fun to write
code. yes, it is. but it's also fun to make money. and
writing innovation applications that people pay for is much
different than writing (or often re-inventing)
infrastructure components. how many of you are out there
trying to re-invent cisco products? i bet zero. you buy
them, unwrap them and turn them on. infrastructure software
should be the same way. only a few people will ever make
money on threads and databases, but many many more will make
money on email messages, calendar events, news articles, and
item sales.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread barries

On Tue, Dec 05, 2000 at 03:54:36PM +, David Hodgkinson wrote:
 
 Is the RH7.0 installation stable? It comes with everything as a DSO
 and _should_ work...

That's the problem: DSOs aren't stable enough, so it all too often
doesn't just work :(.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Nathan Stitt

martin langhoff wrote:
 
 snip.
 Another item that we should really have is a good (and somehow
 sanctioned) RPM that replaces the apache rpm (or deb) included in broken
 distros. Then we can include in the guide and related pages a link for
 [broken-distro-name] users, so they get a suitable replacement with a
 similar config. That's an important issue, because a redhat user has
 other non-standard modules included in his rpm, such as PHP, and
 compiling a *complete* apache, with mod_perl, php and the kitchen sink
 is a daunting task -- and too high an entry price.
 
 anyway, not an easy task ... mmhhh..
 
 martin

Has anyone out there tried the apache toolbox?  It looks like an
interesting program that asks you what options you want in your apache,
then downloads, compiles and installs your apache server.  If it works
as described, it would be a good option to recommend for users with
broken rpms as you describe. It suposedly supports mod_perl, ssl, and
even php all together somehow.

I've never used it, but am planning to give it a shot next time I have
to compile a new server.

Its at: http://www.apachetoolbox.com/


Nathan Stitt
Head Programer, Chief Cook, and Bottle Washer.
Alliance Medical
http://www.allmed.net/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: ANNOUNCE: lingerd 0.91b

2000-12-05 Thread Stas Bekman

On Tue, 5 Dec 2000, Roger Espel Llima wrote:

 Stas Bekman [EMAIL PROTECTED] wrote:
  Very cool!
  Any benchmarks? The theoretical explanation, is quite good for those who
  understand the problem, but far from being convincing for those who don't.
 
 Yep.  Benchmarking with a copy of 'ab' modified to keep the client
 sockets open for a while (like NS and IE do), doing 12 concurrent
 requests on a slow dynamic Apache/mod_perl page, I get:
 
 * without lingerd: number of Apache processes grows from 10 to 39,
   with a peak at 43.  Load average reaches 14.
 
 * with lingerd: number of Apache processes grows from 10 to 20, with
   a peak at 22.  Load average reaches 10.
 
 The speed of the server improved slightly (from 17 to 20 pages per
 second), probably because of the lessened memory and scheduling
 pressure.  

Yup, that't the exact reason. I've seen the same behavior.

 With only 6 concurrent requests, the speed stayed exactly the same
 with or without lingerd, but the number of servers went from 27 to
 12.

Very nice. Of course this significant reduce in a number of processes
required to do the same job, is due to the fast execution time, where the
lingering close time had a significant wait in the request completion
time.

  Also I suppose that you must say that Lingerd becomes the new Achilles
  heel, since if this daemon goes down the whole server won't work.
 
 By default, if Apache can't find lingerd, it will do the lingering
 itself, the usual (slow) way.

That's cool. You didn't mention that.

 If you come to depend on the extra scalability that lingerd brings,
 you can configure Apache to not do lingering_close at all if lingerd
 fails.  It sucks, but it's better to having the server fall over
 with the load...  then again, that's what MaxClients is for.
 
  May I suggest a correction here? "It removes the need for a front-end
  proxy server only if you needed it in first place to solve the downstream
  client feeding problem."
 
 Yep, you're right :)  
 
 A proxy front-end can also serve images and do load-balancing.  In
 the `README' for lingerd I suggest using thttpd and Piranha for each
 of these, but it's true that mod_proxy or mod_rewrite works too.

or even kernel level khttpd if you are on linux.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Nathan Torkington

Stas Bekman writes:
 Luckily Matt has got sick of waiting for someone to work on the advocacy
 of mod_perl and he has just taken over it. Having a good informational
 site is good, but it's not enough. We need to solve the problem of people
 to find this site and wanting to use mod_perl. Solution? Spreading the
 word.

I picture only 10% of people who build web sites ever needing to use
mod_perl directly.  I think they're more likely to use the systems
that are built *in* mod_perl, like Mason, AxKit, and so on.  If
there's a with a lot of information about building web sites with
those systems, then you'll make people happy.

I'm an editor at O'Reilly now, for those who didn't know, and I am
*very* interested in a book on building websites with mod_perl
technology.  That's not the mod_perl book, nor the mod_perl guide, but
a book on using Mason and AxKit and the other solutions to build
bitching dynamic websites.  Anyone interested, contact me
([EMAIL PROTECTED] or [EMAIL PROTECTED]).

 1) Online zines.

The O'Reilly Network is one place to push this.  In January sometime
there'll be a new site launched that will be perfect for this type of
content.  I'll let you know more closer to the date, when *I* will
know more.

The mod_perl advocacy site should have RSS summaries available so that
updates can go into the Meerkat system (meerkat.oreillynet.com).  That
will also raise the image.

Announce the site (I think modperl.com or perl.apache.org should be
the advocacy site, which contains a pointer to the tech docs) in TPJ
and via the Perl News (news.perl.org).

ApacheWeek should mention it.

Nat

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: [ANNOUNCE] New mod_perl Web Site!!!

2000-12-05 Thread Josef

On Tue, Dec 05, 2000 at 10:42:20AM +, Matt Sergeant wrote:
 With a flash of fireworks and champagne I'd like to announce to the world
 our new mod_perl news and advocacy web site:
 
 http://modperl.sergeant.org/

I really like the format and the familiarity of this site.  Looks to be
a really good dab of crazy glue that has been needed to tie us newbies
with the elite.  The only suggestion I would have is a /. style feedback
section.  A place where I can say, "Whoa, there partner, say that again!"
to some 7331 article and have a experience person, or the author, reply
with, "Listen you colt, I won't say this again..."  I know, I know,
that's what this mailing list is for, but really, what new recruit wants
to read 50 hardcore emails a day?

-josef

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Nathan Torkington

Paul writes:
 Any idea what it would take to get a link there from webs like tpj and
 Perl.com?

Those two I can easily make happen.  Send me email saying what you
want a link to, and what you want the link to say.

Writers for perl.com are always wanted.  Pitch your article ideas to
[EMAIL PROTECTED] and he'll work with you to make the good ones happen.

Nat

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread Stas Bekman

Let me stright things out a bit, so you won't get misleaded by my post as
a marketing call.

What we want is very simple. 

1. We want many users, so they will thoroughly test the software and spot
bugs asap, so we -- current users will get a better product.

2. We want more developers, so they will write core mod_perl and 3rd party
modules, again for us current users to re-use and save development
time. The first item is directly linked to the second, as new developers
come out from users.

That's all. The advocacy project is about making people interested in perl
and mod_perl, versus php and java. You see we just loose the testing power
and development power because we cannot attract these people to join *our*
community.

So all the fuss is not about marketing, press and other commercial
bullshit.

It's about people since Open Source without people will not exist.

If we don't ensure that there is a constant income of new people to the
project, we cannot ensure the future of the project.

I hope that our initiative is better understood now.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl Guide 2.0

2000-12-05 Thread Stas Bekman

On 5 Dec 2000, Jorge Godoy wrote:

 On Tue, 5 Dec 2000, [EMAIL PROTECTED] wrote:
 
  3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf
  are already working in the guide, other formats to come).
  
  What other formats do you think people want/need?
 
 info files would be cool. :-) 

is there pod or html 2info converter?


_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Aaron Johnson

mod_perl is NOT PHP.  It wasn't meant to be.
PHP allows for embedding a scripting language inside of HTML and allows for some
"neat" things.  It is also I believe easier to install and setup then a related
mod_perl server.
Reasons/questions of new users:
1) You have to get all kinds of modules and install them just to get to a usable
environment
(lets face it you can't do much with a fresh install on mod_perl unless you already
know mod_perl)
2) Which embedded perl code should I use if I want one? (Embperl, Apache::ASP,
Mason, etc.)
3) What security module do I use?
4) How do I set up session tracking?
5) What good is session tracking?
6) How do I access a database?
7) How do I get mod_perl to work with x database?

Yes some of this is in the guide, but at some point it becomes to easy just to
point a user a document and assume three things:
1) The guide is written generic enough that users at any level can understand it
2) The "real" question is locatable even if the person doesn't know the "real"
question
3) The guide is in a language that is familiar to them.

I am all for advocating the use of mod_perl, but the basics of setup, install and
usability are always going to be key.

Does anyone have any figures on how long it takes to setup a mod_perl server vs. a
php server?
(correctly, not just running)

Before we determine whether to advocate we need to term what and how to advocate.

I have been using mod_perl on Windows and Linux for the last 3 years.  I find it be
an extremely powerful addition to a normal apache server, but the tool kit is too
large and diverse for most people that are simply looking to get a little dynamic
scripting done.

My personal vote for how to advocate, would be better summaries of the various
modules and how they can be used in real life scenarios.
i.e. the thread a few months ago about have a summary of all the embedded Perl
modules (Mason, Embperl, Apache::ASP etc.) outlining their strength and weaknesses
in laymens terms if possible.

We are also advocating the use of Perl which should be much easier since there are
numerous books and example code available in print and online that will work inside
of mod_perl with little or no change.

I just checked out the PHP site and their online manual allows for user comments
that are displayed at the end of each page.  Hmm

Aaron Johnson

martin langhoff wrote:

 kevin montuori wrote:

additionally, i think that some consideration should be given to
how mod_perl is packaged.

 I think it's of crucial importance the fact that a distro as widespread
 as RHLinux 6.x had mod_perl messed up. That has forced quite a lot of
 developers that were trying to get their feet wet with mod_perl to get
 in a complex compile sequence. That's a source of 'bad reputation', and
 of php developers, as the included php was old but working ;)

 I don't know how messed up are other distros regarding apache/mod_perl,
 but making sure the main distros *do* get it right is paramount to make
 mod_perl catch.

 Another item that we should really have is a good (and somehow
 sanctioned) RPM that replaces the apache rpm (or deb) included in broken
 distros. Then we can include in the guide and related pages a link for
 [broken-distro-name] users, so they get a suitable replacement with a
 similar config. That's an important issue, because a redhat user has
 other non-standard modules included in his rpm, such as PHP, and
 compiling a *complete* apache, with mod_perl, php and the kitchen sink
 is a daunting task -- and too high an entry price.

 anyway, not an easy task ... mmhhh..

 martin

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Geoffrey Young



 -Original Message-
 From: Ajit Deshpande [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, December 05, 2000 12:19 PM
 To: kevin montuori
 Cc: [EMAIL PROTECTED]
 Subject: Re: RFC: mod_perl advocacy project resurrection
 
 
 On Tue, Dec 05, 2000 at 10:51:08AM -0500, kevin montuori wrote:
additionally, i think that some consideration should 
 be given to
how mod_perl is packaged.  although it's well documented (and
generally quite simple) there are three kits that need to be
compiled (apache, perl, mod_perl) before the simplest handler
can be tested.  i think to an applications programmer who's
 [..]
 
 I think packaging is key here. For example If we can get 
 RedHat to package 
 the apache and mod_perl RPMs (albeit DSO) such that a basic 
 set of handlers
 and modules just *work*, I think we will be whole lot better off.

I think if we could all agree on a standard newbie package and get RedHat
engineers to agree to it it might go a long way...  I don't remember ever
seeing RedHat asking this list for advice on how it should package mod_perl
(Paul?)

not that they could ever really get everyone on the list to agree :)  but I
think EVERYTHING=1 and a static build would be a majority consensus.

--Geoff 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread Thomas J. Mather

On Tue, 5 Dec 2000, Michael Nachbaur wrote:

 I don't know what I'm getting at here, but I see that Perl is half a
 step behind Java in many ways, except for the performance issues
 (which perl is leagues ahead).  For my company, we're probably going
 Java, but it sorta makes sense for us (we need an enterprise solution
 now...not when the Perl community gets around to it).

How exactly does Java provide a better "enterprise solution" than
Perl?  And how can the Perl community better provide an "enterprise
solution"?

It is true that Java code is generally more cleaner and easier to maintain
than Perl code, but this is because Perl allows you to write bad code,
while Java enforces typing and OO design.  A good Perl coder should
be able to write code that is clean and easy to maintain by following
coding guidelines, and by using OO modules and 'use strict'.

I guess what I'm getting at is that I hear a lot of marketing hype about
Java being a better "enterprise solution", but I'm curious as to what are
the purely technical reasons for using Java over Perl.  What exactly can
you do in Java that you can't do as easily in Perl?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Gerald Richter


additionally, i think that some consideration should be given to
   how mod_perl is packaged.

I know that S.u.S.E. Linux (at least the german version) include a Apache
with mod_perl as DSO ( but I never have tried it, I always compiled
Apache/Perl/mod_perl etc. from the source), but they neither have included
any of the Apache::* modules or Embperl/Mason/ASP/AxKit etc.

I could try to contact them and ask if it's possible to include more of the
Apache modules and maybe the guide.

Gerald

-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:   Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151
WWW:http://www.ecos.de  Fax:  +49 6133 925152
-



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: Response time of a perl script!!!

2000-12-05 Thread Jason Liu

In this situation, I think the bottle neck is establishing connection with
the database.  Apache::DBI helps to maintain persistent database connection.
That's why the latter test is 20 times faster.

Jason


   Hi folks,

   I ran a same perl script twice. First time only under mod_perl,
 and after under mod_perl and Apache::DBI. The response time of both
 experiments was very different. The last was fastest than the first
 approximately 20 times. Is it correctly? If the response time of a perl
 script with mod_perl is bad, I think that it without mod_perl will be
 much worse. I also would like to know if when the apache (with mod_perl)
 starts each child process already has one embedded interpreter or they
 will have only when the first request arrives. Please, if soneone help me
 will be very appreciated. Thanks...

   Edmar,


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread Jay Jacobs



On Tue, 5 Dec 2000, Stas Bekman wrote:

 What we want is very simple. 
 
 1. We want many users, so they will thoroughly test the software and spot
 bugs asap, so we -- current users will get a better product.
 
 2. We want more developers, so they will write core mod_perl and 3rd party
 modules, again for us current users to re-use and save development
 time. The first item is directly linked to the second, as new developers
 come out from users.

I think a good first step in that direction is to have mod_perl modules to
do some of the basic things that early web developers want... a few really
well documented and tailored-for-newbies modules.  I think back a few
years to "Matt's Script Archive", and what that did for perl and
CGI. (Anyone for Apache::Formmail?)

Just some stuff to get the new developer interesting in figuring out how
to compile mod_perl, and to see the benefits of it.  It could even be done
with step-by-step examples, with gradually increasing functions.  ( "Now
move on to Guestbook-DBI" ... "Now add in Apache::Session for such-n-such
functions" )  Perhaps even offer the same modules under mason, embperl
axkit, etc. so folks can take a step in those directions too.

I just think back to the time when I started putting smarts-to-web and
these were the first steps I took, and I looked for that kind of hand
holding as I figured out how to make it work.

Jay Jacobs


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread brian moseley

On Tue, 5 Dec 2000, Nathan Torkington wrote:

 I picture only 10% of people who build web sites ever
 needing to use mod_perl directly.  I think they're more
 likely to use the systems that are built *in* mod_perl,
 like Mason, AxKit, and so on.  If there's a with a lot
 of information about building web sites with those
 systems, then you'll make people happy.

amen! mod_perl is for gearheads. higher layer software is
for people who want to achieve a business goal, or even just
make a personal site. we have a wealth of gearhead-oriented
information, but almost nothing that would convince my php
friends to make the switch to perl or help them migrate a
site.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread brian moseley

On Tue, 5 Dec 2000, Aaron Johnson wrote:

 I am all for advocating the use of mod_perl, but the
 basics of setup, install and usability are always going
 to be key.

really? how many people actually need to configure and
install mod_perl itself? how many people simply need a
really simple templating engine with builtin database
access? aren't their needs very different?

 Does anyone have any figures on how long it takes to
 setup a mod_perl server vs. a php server? (correctly,
 not just running)

i don't have figures, but from experience i know - once i've
compiled httpd, i have almost no real configuration work to
do with php. on the other hand, if i want to set up mason, i
have to write 10-20 lines of perl code and access them with
PerlModule or PerlRequire. if i want multiple mason sites i
have to dig back into that perl script. certainly not
difficult, but kinda irritating, and takes more effort to
maintain, especially across multiple machines.

 Before we determine whether to advocate we need to term
 what and how to advocate.

agree!


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread brian moseley

On Tue, 5 Dec 2000, Gerald Richter wrote:

 I know that S.u.S.E. Linux (at least the german version)
 include a Apache with mod_perl as DSO ( but I never have
 tried it, I always compiled Apache/Perl/mod_perl etc.
 from the source), but they neither have included any of
 the Apache::* modules or Embperl/Mason/ASP/AxKit etc.

i just installed suse 7.0 yesterday. i was psyched to find
that i could install mod_perl (dso) with yast. i then fired
up the cpan shell and installed Bundle::CPAN, Bundle::LWP,
and HTML::Mason. then i had to create my mason handler.pl
and do some httpd.conf tweaking. then i restarted and tried
accessing the page under mason. result: "document contains
no data" dialog in my browser, and no msgs in the error log,
even under LogLevel error. commented out the mason lines in
httpd.conf, restarted, and lived with flat html files.
wasted 30-60 mins that i could have used to do my actual
work.

 I could try to contact them and ask if it's possible to
 include more of the Apache modules and maybe the guide.

please do!



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Eric Strovink

A number of people have been beating around this bush, so why not just mow it down?

A huge win for advocacy would be a small set of complete example applications
targetted at, say, the last two RedHat distros.  Each application should install
itself -- .conf files, .htaccess files, dbm's, directory structures, perl code,
html and templates, correct version of Perl, CPAN packages for any stuff needed,
Apache, mod_perl, mod_ssl, mod_whatever, mysql, database schemas, database
contents, DBI, Session, front-end proxy -- everything.  Each application should
gronk whatever's already there, or rename it out of the way.  Warnings in big
letters.  Tough doots.

Each application package should contain dumbed-down documentation that explains
what it does, and how it does it.

The idea would be to put into people's hands several different complete, debugged,
sophisticated frameworks for building the rest of their application.  All the hard
stuff's done -- .conf, proxying, DBI, session control, cookies, templating,
compiling, building, and so on.  All the newbie has to do is tweak an
already-working example, without necessarily understanding all of what s/he's been
given.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread brian moseley


people won't use the software if you don't give them a
compelling reason. mod_perl and the higher layer systems
that use it are not as easy to configure or program as php,
and they have a lot less support from external software
vendors or relevance inside engineering shops than java. we
are being squeezed from both ends.

i had lunch with doug and jon swartz not too long ago,
talking about the possibility of starting a web application
infrastructure company based on mod_perl and mason. when we
got down to it, the fundamental question was: why not just
use java? and we couldn't find any answer other than "i like
perl better". and that's not a reasonable business
justification.

at some point we're going to run out of hobbyists and others
who /can/ justify using mod_perl-based technologies because
they like perl better.

On Tue, 5 Dec 2000, Stas Bekman wrote:

 Let me stright things out a bit, so you won't get misleaded by my post as
 a marketing call.
 
 What we want is very simple. 
 
 1. We want many users, so they will thoroughly test the software and spot
 bugs asap, so we -- current users will get a better product.
 
 2. We want more developers, so they will write core mod_perl and 3rd party
 modules, again for us current users to re-use and save development
 time. The first item is directly linked to the second, as new developers
 come out from users.
 
 That's all. The advocacy project is about making people interested in perl
 and mod_perl, versus php and java. You see we just loose the testing power
 and development power because we cannot attract these people to join *our*
 community.
 
 So all the fuss is not about marketing, press and other commercial
 bullshit.
 
 It's about people since Open Source without people will not exist.
 
 If we don't ensure that there is a constant income of new people to the
 project, we cannot ensure the future of the project.
 
 I hope that our initiative is better understood now.
 
 _
 Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
 http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
 mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
 http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl Guide 2.0

2000-12-05 Thread Jorge Godoy

On Tue, 5 Dec 2000, [EMAIL PROTECTED] wrote:
 On 5 Dec 2000, Jorge Godoy wrote:
 
 On Tue, 5 Dec 2000, [EMAIL PROTECTED] wrote:
 
  3. Automatic generating of html/ps/pdf/other
  formats. (html/ps/pdf are already working in the guide, other
  formats to come).
  
  What other formats do you think people want/need?
 
 info files would be cool. :-) 
 
 is there pod or html 2info converter?

I don't know.

But I've tried looking after something and I found 'rman'. It can make
*roff code into: ASCII, roff, HTML, SGML (DocBook DTD -- it tries to),
LaTeX  LaTeX2e, RTF, Sections (just section titles), PostScript and
FrameMaker.

From the SGML source we can get info... but it's a conversion from an
already converted code. I don't think it's going to be that good... 


I'll look after something to make pod or html into info and will send
what I find to the list.



See you, 
-- 
Godoy. [EMAIL PROTECTED]

Departamento de Publicações   Conectiva S.A.
Publishing Department Conectiva Inc.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread Stas Bekman

On Tue, 5 Dec 2000, brian moseley wrote:

 
 people won't use the software if you don't give them a
 compelling reason. mod_perl and the higher layer systems
 that use it are not as easy to configure or program as php,
 and they have a lot less support from external software
 vendors or relevance inside engineering shops than java. we
 are being squeezed from both ends.
 
 i had lunch with doug and jon swartz not too long ago,
 talking about the possibility of starting a web application
 infrastructure company based on mod_perl and mason. when we
 got down to it, the fundamental question was: why not just
 use java? and we couldn't find any answer other than "i like
 perl better". and that's not a reasonable business
 justification.
 
 at some point we're going to run out of hobbyists and others
 who /can/ justify using mod_perl-based technologies because
 they like perl better.

You forget about satisfaction. Do you feel happier to program in Java than
Perl? You want your employees to enjoy they work. We spend too much time
working, I want to enjoy most of my working hours. You want me for my
design and architecture skills, you have to give me something in return.
For me salary is much less important factor than satisfaction.

Therefore if the same job can be done with Perl and Java, why not to have
your staff happy? That's the main point I think.

Of course if the bussiness suffers because Perl is not good enough, that's
a different point. Given that at least the same could be done with Perl
and Java, Perl and PHP, Perl and whatever, I want to code in Perl.

Therefore, we should make converts and when more people will prefer coding
in Perl, because they *love* it and it's a legitimate choice, there won't
be a question of whether I can afford doing this project in mod_perl,
because there will be enough mod_perl programmers to take over it.

So to answer your question, the complelling reason is joy and
satisfaction. Given that other factors are at least compatible.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Dave Rolsky

On Tue, 5 Dec 2000, brian moseley wrote:

 i don't have figures, but from experience i know - once i've compiled
 httpd, i have almost no real configuration work to do with php. on the
 other hand, if i want to set up mason, i have to write 10-20 lines of
 perl code and access them with PerlModule or PerlRequire. if i want
 multiple mason sites i

Well, in the future there will be a Mason::Dispatcher (or something)
module to replace the custom code, at least for simpler cases.

This would be _greatly_ helped along if somebody would respond to the
question I posted a week or so back about the seg faults I was getting
when I started working on a custom config system for Mason.  Right now I'm
kind of stalled on that.

-dave

/*==
www.urth.org
We await the New Sun
==*/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Stas Bekman

On Tue, 5 Dec 2000, Eric Strovink wrote:

 A number of people have been beating around this bush, so why not just
 mow it down?
 
 A huge win for advocacy would be a small set of complete example
 applications targetted at, say, the last two RedHat distros.  Each
 application should install itself -- .conf files, .htaccess files,
 dbm's, directory structures, perl code, html and templates, correct
 version of Perl, CPAN packages for any stuff needed, Apache, mod_perl,
 mod_ssl, mod_whatever, mysql, database schemas, database contents,
 DBI, Session, front-end proxy -- everything.  Each application should
 gronk whatever's already there, or rename it out of the way.  
 Warnings in big letters.  Tough doots.
 
 Each application package should contain dumbed-down documentation that
 explains what it does, and how it does it.
 
 The idea would be to put into people's hands several different
 complete, debugged, sophisticated frameworks for building the rest of
 their application.  All the hard stuff's done -- .conf, proxying, DBI,
 session control, cookies, templating, compiling, building, and so on.  
 All the newbie has to do is tweak an already-working example, without
 necessarily understanding all of what s/he's been given.

Sounds like a good project fore Xtropia.com... Gunther?

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread Wiswell, Virginia


stas said:

 What we want is very simple. 
 
 1. We want many users, so they will thoroughly test the 
 software and spot
 bugs asap, so we -- current users will get a better product.
 
 2. We want more developers, so they will write core mod_perl 
 and 3rd party
 modules, again for us current users to re-use and save development
 time. The first item is directly linked to the second, as new 
 developers
 come out from users.

 That's all. The advocacy project is about making people 
 interested in perl
 and mod_perl, versus php and java. You see we just loose the 
 testing power
 and development power because we cannot attract these people 
 to join *our*
 community.
 
 So all the fuss is not about marketing, press and other commercial
 bullshit.
 
 It's about people since Open Source without people will not exist.
 
 If we don't ensure that there is a constant income of new 
 people to the
 project, we cannot ensure the future of the project.
 
 I hope that our initiative is better understood now.
 

ok, it sounds like 'marketing' is a dirty word. how about 'outreach'? 

i just don't see how you plan to attract all these fresh people without
doing something to get the word out. putting links on perl sites is a great
idea, but you're basically just trying to convert the converts. i agree that
getting more people who use perl to adopt mod_perl is a necessity. these are
the people who can contribute to development, thorough testing, and spotting
bugs. 

to get 'many users', 'attract these people to join *our* community' and
'ensure that there is a constant income of new people to the project', you
need to either convert the java/php people or grab the newbies who haven't
chosen a technology yet. these people don't visit perl sites, as a rule.
making installation and configuration as simple as possible, as suggested,
is a great idea. but i still think that mod_perl/perl needs more mainstream
exposure. i'm not talking about selling out, god forbid, but getting some
positive press never hurt. would a link to perl/mod_perl books on a php/java
book page at the o'reilly site be selling out? would a press release from
some corporation stating that they use and have faith in the open souce
mod_perl solution be commercial bullshit? maybe i  AM missing the point, i
don't know.

thanks for listening.

virginia



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread brian moseley

On Tue, 5 Dec 2000, Stas Bekman wrote:

 Therefore if the same job can be done with Perl and
 Java, why not to have your staff happy? That's the main
 point I think.
 
 Of course if the bussiness suffers because Perl is not
 good enough, that's a different point. Given that at
 least the same could be done with Perl and Java, Perl
 and PHP, Perl and whatever, I want to code in Perl.

exactly my point. and in my experience as well as that of
many folks i've spoken with, it's just not the case.

take CPTH web mail. we used Mail::Folder and MIME::*, but we
had to write our own custom subclasses of all of them to
deal with our mail store, with folder sorting, with mime
tree caching, etc. and now that we're moving to an IMAP
backend, we have to write a whole new custom set of
subclasses based on Mail::IMAPClient.

if we'd have been operating in a java environment, we'd have
been able to take advantage of the "insanely great"
JavaMail, which comes out of the box with an IMAP backend. a
prototype IMAP re-implementation of our mail client took
about 3 days, as opposed to the month or more it will take
us to do the perl implementation.

the availability of application server products in the java
world is another example. go look at enhydra enterprise
(http://www.enhydra.org/software/enhydraEnterprise/) and
tell me that something like that exists in the perl world.
and there are many products like this, both commercial and
open source. competition flourishes, and the industry
benefits. there are lots of folks on the market with
experience developing for and operating weblogic. it's
easier to hire and you get better time to market. you don't
have to spend time re-integrating Apache::Session and
Apache::DBI and Apache::WipeMyAss with each new project.
this is why i think AO is some important, altho its scale is
much smaller. it's a first step towards something like
enhydra enterprise for those of us who would, all other
things being equal, prefer to use perl.

 Therefore, we should make converts and when more people
 will prefer coding in Perl, because they *love* it and
 it's a legitimate choice, there won't be a question of
 whether I can afford doing this project in mod_perl,
 because there will be enough mod_perl programmers to
 take over it.
 
 So to answer your question, the complelling reason is
 joy and satisfaction. Given that other factors are at
 least compatible.

yes, but we have to get to that point, and we're not there.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




[OT] mod_perl longevity [Was: mod_perl advocacy project resurrection]

2000-12-05 Thread Ajit Deshpande

On Tue, Dec 05, 2000 at 11:34:49AM -0800, brian moseley wrote:
 i had lunch with doug and jon swartz not too long ago,
 talking about the possibility of starting a web application
 infrastructure company based on mod_perl and mason. when we
 got down to it, the fundamental question was: why not just
 use java? and we couldn't find any answer other than "i like
  ^^^ 
 perl better". and that's not a reasonable business
 justification.

Well, the above question pre-supposes that Java is inherently
*better* than mod_perl for some definition of "better". 

Without getting into a long-drawn holy-war, I dont like the idea 
of "one size fits all" when it comes to web application 
infrastructure technologies. There are and will be perfectly good
reasons to use mod_perl / Java under the reasonable assumption that 
both technologies will evolve in the foreseeable future.

Ajit

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




sponsoring advocacy

2000-12-05 Thread Stas Bekman

Well, here comes a different question. Most of us have very limited
resources on helping the project. The best scenario is when someone is
doing mod_perl coding for his tasks at work and contributes back.

But we are talking about things that require more than that. We need
people with time on their hands to do this different work
(articles/sites/packaging/apps/etc). But it's a time consuming thing, and
many prefer to have some well deserved rest than work for free, even if
they love mod_perl.

So here is the question: Will you or your company support a few people to
do full/part time advocacy which involves talking, coding, helping, and a
lot more. Imagine that we create a group of people who will indirectly
benefit your business by creating the man power (teaching), hype and
acceptance by those who make decisions (media), knowledge base (articles
and cookbooks), more extended help/support at the list level and of course
making the product itself better thru coding.

I'm interested to know two things: 
1) whether there is an interest to sponsor such an endeavor.
2) whether there are people interested to do the work.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Matt Sergeant

On Tue, 5 Dec 2000, Eric Strovink wrote:

 A number of people have been beating around this bush, so why not just
 mow it down?

 A huge win for advocacy would be a small set of complete example
 applications targetted at, say, the last two RedHat distros.  Each
 application should install itself -- .conf files, .htaccess files,
 dbm's, directory structures, perl code, html and templates, correct
 version of Perl, CPAN packages for any stuff needed, Apache, mod_perl,
 mod_ssl, mod_whatever, mysql, database schemas, database contents,
 DBI, Session, front-end proxy -- everything.  Each application should
 gronk whatever's already there, or rename it out of the way.
 Warnings in big letters.  Tough doots.

Do you have any idea how hard this is? Seriously. Because I do. Dave
Rolsky does. And doing this for free is going to be nigh on impossible.

 Each application package should contain dumbed-down documentation that
 explains what it does, and how it does it.

Good writers are really hard to come by.

I don't want to poo-poo on the idea by any means, the *idea* itself is
fine, but the implementation of it is non-trivial.

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: [OT] mod_perl longevity [Was: mod_perl advocacy projectresurrection]

2000-12-05 Thread brian moseley

On Tue, 5 Dec 2000, Ajit Deshpande wrote:

 Well, the above question pre-supposes that Java is
 inherently *better* than mod_perl for some definition of
 "better".

it's true. i stayed away from defining better in that msg,
but explored in a separate one in this thread. suffice to
say, the wealth of existing standards-based components, the
focus on creating a platform for enterprise applications,
and the competitive vendor landscape for development tools
and infrastructure components, all of help define "better"
imo.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread Dave Rolsky

On Tue, 5 Dec 2000, brian moseley wrote:

 infrastructure company based on mod_perl and mason. when we got down
 to it, the fundamental question was: why not just use java? and we
 couldn't find any answer other than "i like perl better". and that's
 not a reasonable business justification.

Isn't it theoretically the same thing in reverse at Java shops?

"Why not use Perl?  I like Java better."

Each has its advantages.  Perl is good for real programmers who are going
to write code to actually solve a problem.  Java is good for monkeys who
think that buying a $100k app server and tweaking it via a monolithic API
will give them what they want.

But I might be biased.


-dave

/*==
www.urth.org
We await the New Sun
==*/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread J. J. Horner

On Tue, Dec 05, 2000 at 11:34:49AM -0800, brian moseley wrote:
 
 people won't use the software if you don't give them a
 compelling reason. mod_perl and the higher layer systems
 that use it are not as easy to configure or program as php,
 and they have a lot less support from external software
 vendors or relevance inside engineering shops than java. we
 are being squeezed from both ends.
 
 i had lunch with doug and jon swartz not too long ago,
 talking about the possibility of starting a web application
 infrastructure company based on mod_perl and mason. when we
 got down to it, the fundamental question was: why not just
 use java? and we couldn't find any answer other than "i like
 perl better". and that's not a reasonable business
 justification.
 
 at some point we're going to run out of hobbyists and others
 who /can/ justify using mod_perl-based technologies because
 they like perl better.
 

As sad as this makes me, it has a ring of truth.  The only reason 
I use mod_perl is to do things that require an Apache module, and 
I don't feel like using C.  I know the performance increase for
mod_perl scripts is amazing, but the learning curve doesn't justify
it.

Perhaps if someone makes a mod_perl based embedded scheme like
Cold Fusion or PHP, that has some special hooks into Apache
for performance that the other solutions don't offer. . .

Honestly, though, I didn't believe the strength of mod_perl
rested on the Mason type modules.  I thought the strength of 
mod_perl was having a perl/Apache API.  Having an easy way to
interact with Apache using everyone's favorite language was 
what sold me on Apache.

Ideas?

JJ
-- 
J. J. Horner
[EMAIL PROTECTED]

"The people who vote decide nothing.
The people who count the vote decide everything."
- Josef Stalin

"The tree of liberty must be watered periodically with the 
blood of tyrants and patriots alike. ... Resistance to tyrants
is obedience to God."
- Thomas Jefferson

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread brian moseley

On Tue, 5 Dec 2000, J. J. Horner wrote:

 Perhaps if someone makes a mod_perl based embedded
 scheme like Cold Fusion or PHP, that has some special
 hooks into Apache for performance that the other
 solutions don't offer. . .

how is mason not like this?

 Honestly, though, I didn't believe the strength of
 mod_perl rested on the Mason type modules.  I thought
 the strength of mod_perl was having a perl/Apache API.  
 Having an easy way to interact with Apache using
 everyone's favorite language was what sold me on Apache.

we very rarely use the apache api anymore. i prefer the
abstraction layer of a templating engine, for ease of use
and for maintainability by larger teams. i used to be
shocked that nobody i worked with wanted to learn how to
configure apache or use its api. now i'm right there with
them. give me Apache::Request and mason and i'm happy.

i know there are several people on the list who swear by
"all handlers, all the time". i've never heard anybody give
a reason for that preference that actually made sense to me.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread brian moseley

On Tue, 5 Dec 2000, Dave Rolsky wrote:

 Each has its advantages.  Perl is good for real
 programmers who are going to write code to actually
 solve a problem.  Java is good for monkeys who think
 that buying a $100k app server and tweaking it via a
 monolithic API will give them what they want.

c'mon dude, offer something constructive to the thread or
stay out of it.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Gerald Richter


 i don't have figures, but from experience i know - once i've
 compiled httpd, i have almost no real configuration work to
 do with php. on the other hand, if i want to set up mason, i
 have to write 10-20 lines of perl code and access them with
 PerlModule or PerlRequire. if i want multiple mason sites i
 have to dig back into that perl script. certainly not
 difficult, but kinda irritating, and takes more effort to
 maintain, especially across multiple machines.


That's what I always tried to avoid within the configuration of Embperl. I
have tried to keep it as simple as possible for the first start. If you have
mod_perl up and running, you just tell Apache to handle for example .epl
files by HTML::Embperl and your are done. (exactly 6 lines to copy and paste
form the Embperl docs into yout httpd.conf ), but as I understand Jonathan
he (and Mason) has a slightly other intention in this area.

Gerald

-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:   Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151
WWW:http://www.ecos.de  Fax:  +49 6133 925152
-




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread Matthew Kennedy



"Thomas J. Mather" wrote:
 
 On Tue, 5 Dec 2000, Michael Nachbaur wrote:
 
  I don't know what I'm getting at here, but I see that Perl is half a
  step behind Java in many ways, except for the performance issues
  (which perl is leagues ahead).  For my company, we're probably going
  Java, but it sorta makes sense for us (we need an enterprise solution
  now...not when the Perl community gets around to it).

Server side performance of Java shouldn't be an issue for you.

 
 How exactly does Java provide a better "enterprise solution" than
 Perl?  And how can the Perl community better provide an "enterprise
 solution"?

I've worked with both (Java 2 EE and tools like Apache::ASP/Mason). What
people want out of an "enterprise solution" is a middle tier which is
not tied into the presentation. When you free your process decisions
from the presentation in that way, you can implement a B2B type
transactions much more easily. The rationale for J2EE is already defined
quite well in this way.

snip

 I guess what I'm getting at is that I hear a lot of marketing hype about
 Java being a better "enterprise solution", but I'm curious as to what are
 the purely technical reasons for using Java over Perl.  What exactly can
 you do in Java that you can't do as easily in Perl?

Transaction support for your business logic is easy in J2EE. It's not
clear how you do this in Perl? By CORBA ORBs and TMs I suspect, but
there's no real standard framework for that in Perl. There are other
lesser advantages too... standardized XML support is one of them
(topical for me right now).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread martin langhoff

Eric Strovink wrote:
 
 A number of people have been beating around this bush, so why not just mow it down?
 
 A huge win for advocacy would be a small set of complete example applications
 targetted at, say, the last two RedHat distros.  

I see a suitable target there ... maybe a SRPM bundling:

Apache + mod_perl + libapreq + DBI + DBD::Mysql + HTML::Embperl +
Apache::ASP + Template Toolkit ... 

I guess it's important that we build a SRPM so the build sequence uses
the local perl intallation



martín

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread Drew Taylor

Stas Bekman wrote:
 
 On Tue, 5 Dec 2000, brian moseley wrote:
 
 
  people won't use the software if you don't give them a
  compelling reason. mod_perl and the higher layer systems
  that use it are not as easy to configure or program as php,
  and they have a lot less support from external software
  vendors or relevance inside engineering shops than java. we
  are being squeezed from both ends.
 
  i had lunch with doug and jon swartz not too long ago,
  talking about the possibility of starting a web application
  infrastructure company based on mod_perl and mason. when we
  got down to it, the fundamental question was: why not just
  use java? and we couldn't find any answer other than "i like
  perl better". and that's not a reasonable business
  justification.
 
  at some point we're going to run out of hobbyists and others
  who /can/ justify using mod_perl-based technologies because
  they like perl better.
 
 You forget about satisfaction. Do you feel happier to program in Java than
 Perl? You want your employees to enjoy they work. We spend too much time
 working, I want to enjoy most of my working hours. You want me for my
 design and architecture skills, you have to give me something in return.
 For me salary is much less important factor than satisfaction.
 
 Therefore if the same job can be done with Perl and Java, why not to have
 your staff happy? That's the main point I think.
 
 Of course if the bussiness suffers because Perl is not good enough, that's
 a different point. Given that at least the same could be done with Perl
 and Java, Perl and PHP, Perl and whatever, I want to code in Perl.

I know this goes a little off topic, so I apologize in advance.

One big sticking point with Perl I'm just starting to run into is XML.
Yes, Perl has great XML modules, and many more promising ones. But where
is the _validating_ XML parser? I'm doing some XML work where a
validating parser would be very nice, speed hit or not. I can work
around it easily (this is perl :-), but it would save me some work.

The XML  Java combination has a LOT more corporate resources (read $$$)
focused on it than Perl  XML. How many Java-based XML software
announcements have you seen lately? Now compare that to Perl-based XML
modules. The numbers don't compare very well. What can we do about this?
I can't help write a validating parser, but I would be happy to help
test it out. IMHO, more XML support would help sell perl into more
corporate settings. Java is big into buzzwords, and XML is one of the
biggest there is at the moment. And as we know PHBs like buzzwords, so
that is one more point in Java's favor.

I'm quite happy being a perl programmer, although I do plan on learning
other languages in the future. I love perl. As such, I'm definately all
for keeping my future job market as large as possible. If getting perl
more into the corporate eye helps that goal, then what do I need to do
as a "little guy"?

-- 
Drew Taylor
Software Engineer
OpenAir.com - Making Business a Breeze!
Open a free account today at www.openair.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread Matt Sergeant

On Tue, 5 Dec 2000, brian moseley wrote:

 the availability of application server products in the java
 world is another example. go look at enhydra enterprise
 (http://www.enhydra.org/software/enhydraEnterprise/) and
 tell me that something like that exists in the perl world.

http://www.mediasurface.com

Sadly though, its only one product in a sea of Java products.

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread darren chamberlain

kevin montuori ([EMAIL PROTECTED]) said something to this effect:
  David Hodgkinson writes:
   prebuilt solves the problem nicely for people running linux;
   however, that's not everybody.  i'm sure there are sun shops out
   there without the sysadmin expertise to download and compile
   mod_perl properly.  i'd rather see the configure/compile process
   simplified than try to provide binaries for a dozen platforms --
   that would allow the folks who'd be tied to compiling each new
   release to do more interesting and profitable things.

Perhaps the solution is a complete, precompiled package, something that
has Perl, Apache, mod_perl, and all the required modules prebuilt, in
various formats: RPM, deb, tgz, Solaris pkg, and just regular tarballs.

ActiveState has a generic, relocatable tarball of ActivePerl that can
be moved around. It's very nice -- simple to install, answer a few
questions, and the whole things gets put where you want it.

With a handful of maintainers and a lot of diskspace, a number of 
configurations can be created.

This is something I'd be willing to devote some time to. If anyone finds
a home for something like this, consider me a volunteer.

(darren)

-- 
It has long been an axiom of mine that the little things are infinitely
the most important.
-- Arthur Conan Coyle

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Ajit Deshpande

On Tue, Dec 05, 2000 at 08:26:35PM +, Matt Sergeant wrote:
  application should install itself -- .conf files, .htaccess files,
  dbm's, directory structures, perl code, html and templates, correct
  version of Perl, CPAN packages for any stuff needed, Apache, mod_perl,
  mod_ssl, mod_whatever, mysql, database schemas, database contents,
  DBI, Session, front-end proxy -- everything.  Each application should
  gronk whatever's already there, or rename it out of the way.
  Warnings in big letters.  Tough doots.
 
 Do you have any idea how hard this is? Seriously. Because I do. Dave
 Rolsky does. And doing this for free is going to be nigh on impossible.

IMHO, it shouldnt be that difficult if you make some good assumptions. 
For example, how difficult will it be to maintain the following package:

   1. Assume Perl 5.5.3 OR 5.6.0
   2. Assume latest Apache and static mod_perl
   3. Assume latest Apache::DBI, Apache::Session,
   4. Assume latest HTML::Mason (I cant speak for the others, yet)
   5. Assume latest MySQL

Now, with the above, I think we can maintain a basic demo, templating
system with session management using Apache::DBI fairly easily.

Ajit

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Matt Sergeant

On Tue, 5 Dec 2000, Ajit Deshpande wrote:

 On Tue, Dec 05, 2000 at 08:26:35PM +, Matt Sergeant wrote:
   application should install itself -- .conf files, .htaccess files,
   dbm's, directory structures, perl code, html and templates, correct
   version of Perl, CPAN packages for any stuff needed, Apache, mod_perl,
   mod_ssl, mod_whatever, mysql, database schemas, database contents,
   DBI, Session, front-end proxy -- everything.  Each application should
   gronk whatever's already there, or rename it out of the way.
   Warnings in big letters.  Tough doots.
 
  Do you have any idea how hard this is? Seriously. Because I do. Dave
  Rolsky does. And doing this for free is going to be nigh on impossible.

 IMHO, it shouldnt be that difficult if you make some good assumptions.
 For example, how difficult will it be to maintain the following package:

1. Assume Perl 5.5.3 OR 5.6.0
2. Assume latest Apache and static mod_perl
3. Assume latest Apache::DBI, Apache::Session,
4. Assume latest HTML::Mason (I cant speak for the others, yet)
5. Assume latest MySQL

 Now, with the above, I think we can maintain a basic demo, templating
 system with session management using Apache::DBI fairly easily.

I can only suggest you try it as I speak from experience.

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Performance with Apache::Resource

2000-12-05 Thread mapg

Hi,

We have installed Apache::Resource working of course with BSD::Resource and 
this combination is running fine.

Now, we want to improve the performance of our server and would like to know 
the best values for Apache::Resource module, enabling of disabling some 
commands at our httpd.conf too.

Our server is running at a shared-dedicated server with a Pentium III 700 
Mhz and a quote of CPU of 8%. (This is a new server formula today. We have 
all features of a dedicated server but shared with 14 websites and with a 
specific CPU and Ram quote)

We have 64 Mb of Ram memory and a maximum swap file capacity of 192 Mb
running at Seagate Cheetah 10.000 rpm Ultra166 Scsi.

Software installed: Linux Red Hat 6.2, with Apache 1.3.9 (Unix), Mod_perl 1.24,
and Perl 5.005_03, suEXEC and Make 3.79 

Our values are:

At Apache::Resource

sub DEFAULT_RLIMIT_DATA  () { 64 } #data (memory) size in MB
sub DEFAULT_RLIMIT_AS() { 64 } #address space (memory) size in MB
sub DEFAULT_RLIMIT_CPU   () { 60*6 } #cpu time in seconds
sub DEFAULT_RLIMIT_CORE  () { 0  } #core file size (MB)
sub DEFAULT_RLIMIT_RSS   () { 16 } #resident set size (MB)
sub DEFAULT_RLIMIT_FSIZE () { 10 } #file size  (MB)
sub DEFAULT_RLIMIT_STACK () { 20 } #stack size (MB)

PerlModule Apache::Resource

PerlSetEnv PERL_RLIMIT_DATA 32
PerlSetEnv PERL_RLIMIT_AS 32
PerlSetEnv PERL_RLIMIT_CPU 20

PerlChildInitHandler Apache::Resource

And a brief of our httpd.conf file:

- Timeout 300
- KeepAlive On
- MaxKeepAliveRequests 100
- KeepAliveTimeout 7
- MinSpareServers 5
- MaxSpareServers 10
- StartServers 10
- MaxClients 90
- MaxRequestsPerChild 5
- LoadModule perl_modulemodules/libperl.so
- AddModule mod_perl.c

IfModule mod_perl.c
  Alias /perl/ /home/httpd/perl/
  Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Options +ExecCGI
  /Location
/IfModule

- #PerlSetEnv PERL_RLIMIT_DEFAULTS On
(NOTE: We had to comment that out because it was causing a memory shortage in httpd.)
- PerlModule Apache::Resource
- PerlChildInitHandler Apache::Resource

Statistics:

We have disabled the access_log file to improve the performance because we 
have another tools to see our traffic. Anyway, maybe if we improve the values
at Apache::Resource and httpd.conf we can enable it again.

We have a traffic of 3,100 users daily with 10 minutes of staying (in average).

Number of CGIs used every day: 11,209. Transferred: 182 Mb (only CGIs)
Bandwidth: 1 GB daily.

We would like to received some advices to configure the maximum performance
with this class of server, because Apache::Resource has saved the life of our
site, and now, we would like to improve a little more its features.

Thank you very much in advance and thank you very much to Apache project,
a brilliance of freedom at Internet.

Miguel Angel Perez Garcia
3Dup.com - The Computer Graphics Portal


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread kevin montuori

 brian moseley writes:

  bm i know there are several people on the list who swear by "all
  bm handlers, all the time". i've never heard anybody give a reason
  bm for that preference that actually made sense to me.

  i'm not sure about "all handlers, all the time" but a good deal
  of what i'm using mod_perl for is session management, credential
  maintenance, custom logging, on-the-fly compression, and other
  "housekeeping" tasks.  i think only 10% of my handlers are
  content handlers, the other 90% do things neither CGI nor an
  application server are going to do.

  if for no other reason than time to market, it's nice to have
  access to the server API in Perl rather than C.  it took only
  hours to whomp up handlers to help integrate netegrity's
  siteminder product into our existing site; it would have been
  weeks if it had to be written in C.

  cheers,
  k.

-- 
kevin montuori

support independent booksellers -- http://www.booksense.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Problem Building Mod_Perl 1.24_01 under AIX and gcc

2000-12-05 Thread William R. Mattil

Hello,

If anyone could help with this it would be greatly appreciated.

Email response would be preferred. Thanks


IBM RISC 6000 gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)
apache_1.3.14
mod_perl-1.24_01

perl is perl-5.6.0


mod_perl - 

$ cd mod_perl-1.XX
 $ perl Makefile.PL \
 APACHE_SRC=../apache_1.3.X/src \
 DO_HTTPD=1 \
 USE_APACI=1 \
 PREP_HTTPD=1 \
 EVERYTHING=1 \
 [...]
 $ make
 $ make test
 $ make install
$ cd apache_1.3.X
 $ ./configure \
 --prefix=/path/to/install/of/apache \
 --activate-module=src/modules/perl/libperl.a \
 [...]
 $ make
 
results in:


cd ..; gcc  -DAIX=42 -U__STR__ -DAIX_BIND_PROCESSOR -DMOD_PERL
-DUSE_PERL_SSI -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE
-fno-strict-aliasing -I/usr/local/include -DUSE_HSREGEX -DUSE_EXPAT
-I./lib/expat-lite -DNO_DL_NEEDED `./apaci` -I.
-I/usr/local/lib/perl5/5.6.0/aix/CORE  -lm  -o helpers/dummy
helpers/dummy.c   -Xlinker
-bE:/usr/local/lib/perl5/5.6.0/aix/CORE/perl.exp  -L/usr/local/lib
/usr/local/lib/perl5/5.6.0/aix/auto/DynaLoader/DynaLoader.a
-L/usr/local/lib/perl5/5.6.0/aix/CORE -lperl -lnsl -ldbm -ldl -lld -lm
-lc -lbsd -lPW -liconv -bE:./modules/perl/mod_perl.exp 
gcc: installation problem, cannot exec `cpp': No such file or directory
gcc: file path prefix
`/usr/local/lib/gcc-lib/E:./modules/perl/mod_perl.exp/egcs-2.91.60/'
never used
make: The error code from the last command is 1.


Stop.
 Error Output for sanity check 
= End of Error Report =

 Aborting!

Regards

Bill
-- 

William R. Mattil   | Failure is not an Option ... It's bundled 
Sr. System Aministrator | with all Microsoft Products   
(972) 399-4106  |

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection (and a proposal!)

2000-12-05 Thread kyle dawkins

Everybody

This whole call for mod_perl advocacy is definitely a good thing.  But we're 
not going to get anywhere unless we understand the problem in detail.  We can 
run around all we like talking numbers and touting the virtues of mod_perl 
but it's not going to actually do anything unless we address some fundamental 
issues.  I don't claim to know the answers to these problems, but I do think 
I can at least start the ball rolling the right direction to get others 
thinking about what next.

If we're on this list, there's a good chance we think we have a good 
understanding of mod_perl.   Or at least a good understanding of the parts of 
the massive mod_perl beastie that we use.  I use it all day every day but 
don't claim to know anything about Authentication, for example.   I'm sure I 
could read the chapters in the eagle book and figure it out, but I don't know 
anything about it now.

So, making that assumption, I want to bring up a few issues that I see as 
crucial.

1. We are worried that mod_perl is not being adopted as a server technology 
in enough places.   This is actually TWO problems, not one, and to treat is 
as one is missing the point.   There are TWO different kinds of developer out 
there.  The first is someone who is probably not a programmer by trade, but 
has picked up CGI and/or PHP/ASP programming from a "21 days" book or by 
reading through examples.  There are a number of reasons why *these* people 
have not jumped all over mod_perl... I'm sure we all know what those reasons 
are.The second group of people are *engineers* (or *developers*).  These 
people need something different out of mod_perl.  They need good docs, 
examples, stability, community support, and FOUNDATION CLASSES (more on this 
later)

2. Perl
Let's face it, we love Perl, but a lot of people don't, because *they don't 
understand it*.  Remember, a lot of people might have looked at Perl 4 when 
it was a disastrous hodgepodge and not looked at it since.  Perl 5 is an 
infinitely better language than 4, but most people don't know that.  In order 
for Perl to be acceptable in larger institutions with an already-established 
software engineering group, changes to Perl itself need to be made.  See more 
below.

3. Installation/setup
Ok, so if you have Linux, it's a piece of cake... download all the sources, 
follow the README's, and go.  But what if you don't have Linux?  Or you 
aren't root, and what if you need access to httpd.conf to keep changing 
stuff?  And developers are going to need to cycle the server all the time, so 
they need the ability to do that, too... it's definitely a weak point.  I can 
install any one of the Java-based web application frameworks and be 
developing immediately.

4. Isolation
A lot of mod_perl projects (or even Perl projects in general) tend to be 
one-person shows... maybe I'm wrong, and I'd love it if people could correct 
me!  But in my observation, we have a lot of programmers working in 
isolation.  This is bad.  

5. Foundation libraries
Because of the open nature of the CPAN community, there are a lot of great 
modules floating around out there.  However, there is no real API consistency 
in them, and this will cause newcomers to Perl a fair amount of trouble.   
Moreover, we're not going to get anywhere in the enterprise if people insist 
on using HTML templating systems that allow the embedding of code within 
HTML.  It's straight up and down a total disaster and no right-minded 
software architect would ever consider it.

which brings me to...

6. Engineering
The Perl community is made up of a truly eclectic group of people, which is 
an amazing strength.  However, it's also an amazing weakness:  I get the 
impression that very few programmers in the Perl community spend a lot of 
time *reading* books on software engineering and techniques thereof... and 
that lack of knowledge tends to bleed over into a lot of code out there.  We 
have a HUGE problem in the community of the "coder superstar" mentality... 
which is very dangerous.  Perl allows far too many tricks, and often code 
ends up totally unmaintainable and unreadable because some coding yahoo put 
in some glory-code.  It happens in many languages, true, but Perl is the 
ideal environment for it.

-- SO --

I hope you guys can give these points some thought.  I could be "smoking 
grass" but I think I'm on target on most of my points and I'd love to hear 
what you guys think too.   In the meantime, here are some ideas that might go 
down well (or not!):

* We implement a "mode" under mod_perl, kind of like "use strict", that 
suddenly forces Perl to behave well from an object-oriented standpoint.  By 
this, I mean taking some of the power away from Perl that causes trouble, 
like allowing anyone to write instance data on an arbitrary instance of a 
class...
* We "homogenise" some foundation classes.  This means we create a *suite* of 
classes that have consistent API, are designed together as a framework, 

Re: mod_perl advocacy project resurrection

2000-12-05 Thread Ben Cottrell

On Tue, 5 Dec 2000 12:40:47 -0800 (PST), brian moseley wrote:
 On Tue, 5 Dec 2000, Dave Rolsky wrote:
 
  Each has its advantages.  Perl is good for real
  programmers who are going to write code to actually
  solve a problem.  Java is good for monkeys who think
  that buying a $100k app server and tweaking it via a
  monolithic API will give them what they want.
 
 c'mon dude, offer something constructive to the thread or
 stay out of it.

Except that he's absolutely right.

I have personal experience -- my company is ripping out its elegant
mod_perl based architecture and replacing it with *cough* the
j-word *cough*.

mod_perl is the superior technology, hands down. This is coming from
someone who's an avowed perl hater, too. I loathe perl itself, but
have to admit that mod_perl, when you compare it to the alternatives
in the dynamic-web-content space, just plain rules.

Just one example... my company ran into a bug in mod_perl a while ago...
so what did we do? we fixed it, and submitted a patch. If we'd been
using the J-word, we'd have been stuck. Tell me one big-name app server
that's written in C and that'll let you download the source and fix
bugs.

disney gratuitous="yes"
Kinda hard to laugh hangin' there in one o' them "virtual machines", Rob...
/disney

~Ben
 (this message comes guaranteed to offend absolutely everybody in
 some fashion or other)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Apache 1.3.14 build

2000-12-05 Thread Wang, Pin-Chieh

I am trying to build apache v.1.3.14 with Mod_perl v. 1.24 using APACI
I am using Perl 5.6 build 620 - the latest

I ran perl Makefile.PL under mod_perl-1.24 directory
The system created Makefile in support,regex. directories
but terminated prematually with warning message for "Apache Version 1.3.0
required, aborting.."

Any body knows why?
Should I go back to Apache 1.3.0?

Thanks for any help

PC Wang


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread Michael Nachbaur

The issue here is not the underlying architecture.  I have seen so-called "Enterprise" 
solutions which are based on the most flakey of ideas, but are sold with a $150k+ 
pricetag.  Why?  Because of the integraiton.  Because of the support.

I a large company, you cannot *afford* to have the ubergeek cureall solution.  What if 
the guy gets hit by a bus?  What if he goes to another company?  You can't afford that 
kind of situation.  What do you do in that case?  Make the system easy enough to use 
and understand, that you can have 5-ubergeek types at the company.  Sure the system 
isn't a screamer, but atleast it doesn't take a genious to understand.

Also, systems like EmbPerl, HTML::Mason and Axkit/Cocoon work wonders for shops with 
under 10 developers.  What happens when you have 20 programmers, 15 workflow people, 
45 content creators, 10 photographers, 20 HTML designers / producers, 30 
merchandisers, 30 marketers and a host of misc. consultant copywriters?  How do you 
coordinate everything?  A large online retailer, news site, portal, you name it...has 
a *lot* of employees.  *That* is what an Enterprise is...and anyone who says you can 
"get by" with an HTML::Mason is diluted.

Now, I use HTML::Mason, and I love it...for my personal website.  I'm sure many 
organizations can get by with it.  But, thats not what I'm talking about, and thats 
where Java is winning.  What happens when all those programmers working on Java 
solutions decide to build something at home?  They'll use Java.

If you remember, Apple tried to appeal to schools and home users, and M$ focused on 
business.  Who has all the marketshare now?

The answer isn't in the hobbiest or in the small sites.  For longevity and mindshare, 
you must go into the big businesses.

My company is a Perl shop, through and through.  We would rather go to Perl, but the 
problem is that theres *nothing* out there.  Please prove me wrong.

--man
Michael A. Nachbaur

-Original Message-
From: Thomas J. Mather [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 05, 2000 10:25 AM
To: [EMAIL PROTECTED]
Subject: Re: mod_perl advocacy project resurrection


On Tue, 5 Dec 2000, Michael Nachbaur wrote:

 I don't know what I'm getting at here, but I see that Perl is half a
 step behind Java in many ways, except for the performance issues
 (which perl is leagues ahead).  For my company, we're probably going
 Java, but it sorta makes sense for us (we need an enterprise solution
 now...not when the Perl community gets around to it).

How exactly does Java provide a better "enterprise solution" than
Perl?  And how can the Perl community better provide an "enterprise
solution"?

It is true that Java code is generally more cleaner and easier to maintain
than Perl code, but this is because Perl allows you to write bad code,
while Java enforces typing and OO design.  A good Perl coder should
be able to write code that is clean and easy to maintain by following
coding guidelines, and by using OO modules and 'use strict'.

I guess what I'm getting at is that I hear a lot of marketing hype about
Java being a better "enterprise solution", but I'm curious as to what are
the purely technical reasons for using Java over Perl.  What exactly can
you do in Java that you can't do as easily in Perl?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread Matt Sergeant

On Tue, 5 Dec 2000, (Matthew Kennedy) wrote:

  I guess what I'm getting at is that I hear a lot of marketing hype about
  Java being a better "enterprise solution", but I'm curious as to what are
  the purely technical reasons for using Java over Perl.  What exactly can
  you do in Java that you can't do as easily in Perl?

 Transaction support for your business logic is easy in J2EE. It's not
 clear how you do this in Perl? By CORBA ORBs and TMs I suspect, but
 there's no real standard framework for that in Perl. There are other
 lesser advantages too... standardized XML support is one of them
 (topical for me right now).

XML support I think we have mostly covered now (or maybe you disagree?).

But I'd really love to hear some rational discussion on transaction object
support. There are open source J2EE implementations - would it be possible
to look a porting the transaction management components of that to Perl?
Would this be desirable? Personally I put all transaction critical stuff
in the database, and rely on RDBMS transaction support, but I've never
done J2EE, so I'm curious as to the advantages.

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Jens-Uwe Mager

On Tue, Dec 05, 2000 at 04:14:13PM -0500, darren chamberlain wrote:

 Perhaps the solution is a complete, precompiled package, something that
 has Perl, Apache, mod_perl, and all the required modules prebuilt, in
 various formats: RPM, deb, tgz, Solaris pkg, and just regular tarballs.

Exactly, and one has to make sure that perl is in the prebuilt package
as well, probably even using a seperate path from the normally used perl
locations, for example /usr/local/apache/perl for the perl installation.
It is crucially important to have all of apache, apache modules,
mod_perl and perl moduless built using a exactly the same compiler and a
coherent set of compiler flags.

-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:  +49 5131 709320
FAX:+49 5131 709325
Internet:   [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread brian moseley

On Tue, 5 Dec 2000, Ajit Deshpande wrote:

 IMHO, it shouldnt be that difficult if you make some
 good assumptions.  For example, how difficult will it be
 to maintain the following package:
 
1. Assume Perl 5.5.3 OR 5.6.0
2. Assume latest Apache and static mod_perl
3. Assume latest Apache::DBI, Apache::Session,
4. Assume latest HTML::Mason (I cant speak for the others, yet)
5. Assume latest MySQL
 
 Now, with the above, I think we can maintain a basic
 demo, templating system with session management using
 Apache::DBI fairly easily.

fwiw, those are exactly the components the current version
of ao supports out of the box.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: mod_perl advocacy project resurrection

2000-12-05 Thread brian moseley

On Tue, 5 Dec 2000, Matt Sergeant wrote:

 On Tue, 5 Dec 2000, brian moseley wrote:
 
  the availability of application server products in the java
  world is another example. go look at enhydra enterprise
  (http://www.enhydra.org/software/enhydraEnterprise/) and
  tell me that something like that exists in the perl world.
 
 http://www.mediasurface.com
 
 Sadly though, its only one product in a sea of Java
 products.

doesn't look like enhydra enterprise at all. i'm not talking
about a content management system, i'm talking about a
scalable middle tier service upon which any type of
application can be built.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Perl vs Java (XML Modules)

2000-12-05 Thread Matt Sergeant

On Tue, 5 Dec 2000, Drew Taylor wrote:

 I know this goes a little off topic, so I apologize in advance.

I changed the topic for you :-)

 One big sticking point with Perl I'm just starting to run into is XML.
 Yes, Perl has great XML modules, and many more promising ones. But where
 is the _validating_ XML parser? I'm doing some XML work where a
 validating parser would be very nice, speed hit or not. I can work
 around it easily (this is perl :-), but it would save me some work.

XML::Checker.
Also see www.perl.com which links to Kip Hampton's XML.com article about
validating using XPath.

 The XML  Java combination has a LOT more corporate resources (read $$$)
 focused on it than Perl  XML. How many Java-based XML software
 announcements have you seen lately? Now compare that to Perl-based XML
 modules. The numbers don't compare very well. What can we do about this?

Very little, except produce our own XML modules that can do our work. And
you can help by praising those that do produce good XML modules and by
using the modules that work rather than those that don't (hint: XML::XPath
vs XML::DOM with XML::XQL). Apart from validation, what are you missing?

 I can't help write a validating parser, but I would be happy to help
 test it out. IMHO, more XML support would help sell perl into more
 corporate settings. Java is big into buzzwords, and XML is one of the
 biggest there is at the moment. And as we know PHBs like buzzwords, so
 that is one more point in Java's favor.

Actually XML is one area where mod_perl kicks Java's butt in some ways.
AxKit is *faster* than Cocoon. Please test and see for yourself if you
don't believe me. And building XML based web sites with AxKit is *really*
easy. I built modperl.sergeant.org in 10 days of spare time, including a
content management system for the news articles (note that half of the CMS
code is just a plain mod_perl handler). I'll stick an article online
shortly about how the site is constructed.

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread brian moseley

On Tue, 5 Dec 2000, kevin montuori wrote:

   i'm not sure about "all handlers, all the time" but a good deal
   of what i'm using mod_perl for is session management, credential
   maintenance, custom logging, on-the-fly compression, and other
   "housekeeping" tasks.  i think only 10% of my handlers are
   content handlers, the other 90% do things neither CGI nor an
   application server are going to do.

in fact, these are exactly the problems ao is meant to
solve. the idea is that for now, we provide a presentation
tier environment with hooks to allow you to integrate middle
tier functionality, but eventually it would be nice to also
create a real j2ee like environment with separate front and
middle tiers, where presentation and business logic can be
varied and scaled separately.

   if for no other reason than time to market, it's nice to have
   access to the server API in Perl rather than C.  it took only
   hours to whomp up handlers to help integrate netegrity's
   siteminder product into our existing site; it would have been
   weeks if it had to be written in C.

yup, it's always going to be nice to have direct access to
low-level components. as someone pointed out earlier, some
people will always require it. i'm shooting to make 80% of
people happy rather than 20%.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread Drew Taylor

barries wrote:
 
 On Tue, Dec 05, 2000 at 04:10:01PM -0500, Drew Taylor wrote:
  I know this goes a little off topic, so I apologize in advance.
 
  One big sticking point with Perl I'm just starting to run into is XML.
  Yes, Perl has great XML modules, and many more promising ones. But where
  is the _validating_ XML parser?
 
 Will XML::Checker::Parser do?

Hmmm, looks interesting. I'll check into it. Any experience (good or
bad) with it? I see that it relies on XML::Parser. How well does
XML::Parser handle the newly available external DTD feature?

  I'm doing some XML work where a
  validating parser would be very nice, speed hit or not. I can work
  around it easily (this is perl :-), but it would save me some work.
 
 plugAnd, if you want to validate while writing, XML::ValidWriter
 might help/plug.

My biggest problem with XML::Writer (and hence XML::ValidWriter) is that
I can't write to a string, unless there is some hackish workaround. I
remember someone talking about an IO::String sort of module, but it
sounds like using a sledhammer to drive a nail. ;-) I did actually check
out XML::Writer, and even went to far as to replace the IO handle stuff
with a plain old string. But then decided to use something else. While I
love the idea of validating as I write XML, it doesn't help on the other
end. :-(

-- 
Drew Taylor
Software Engineer
Phone: 617.351.0245
Fax 617.350.3496
OpenAir.com - Making Business a Breeze!
Open a free account today at www.openair.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread Perrin Harkins

On Tue, 5 Dec 2000, Matthew Kennedy wrote:
 I've worked with both (Java 2 EE and tools like Apache::ASP/Mason).
 What people want out of an "enterprise solution" is a middle tier
 which is not tied into the presentation. When you free your process
 decisions from the presentation in that way, you can implement a B2B
 type transactions much more easily. The rationale for J2EE is already
 defined quite well in this way.

Mr. Mather's Apache::PageKit module does a good job of implementing the
model/view/controller paradigm in mod_perl.

 Transaction support for your business logic is easy in J2EE. It's not
 clear how you do this in Perl?

Use an RDBMS.

- Perrin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread Perrin Harkins

On Tue, 5 Dec 2000, brian moseley wrote:
 i know there are several people on the list who swear by
 "all handlers, all the time". i've never heard anybody give
 a reason for that preference that actually made sense to me.

That usually comes up in the context of handlers vs. Apache::Registry.  
I've never heard anyone argue that you should always write handlers from
scratch instead of developing (or downloading) a framework along the lines
of your AO project.

- Perrin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Perl vs Java (XML Modules)

2000-12-05 Thread Drew Taylor

Matt Sergeant wrote:
 
 On Tue, 5 Dec 2000, Drew Taylor wrote:
 
  I know this goes a little off topic, so I apologize in advance.
 
 I changed the topic for you :-)

But now it seems like flame bait ;-)

  One big sticking point with Perl I'm just starting to run into is XML.
  Yes, Perl has great XML modules, and many more promising ones. But where
  is the _validating_ XML parser? I'm doing some XML work where a
  validating parser would be very nice, speed hit or not. I can work
  around it easily (this is perl :-), but it would save me some work.
 
 XML::Checker.
 Also see www.perl.com which links to Kip Hampton's XML.com article about
 validating using XPath.

I'll look more into XML::Checker. Apart from being alpha, it seems like
it will work nicely. I guess I could help with the alpha status if I
choose. :-)

  The XML  Java combination has a LOT more corporate resources (read $$$)
  focused on it than Perl  XML. How many Java-based XML software
  announcements have you seen lately? Now compare that to Perl-based XML
  modules. The numbers don't compare very well. What can we do about this?
 
 Very little, except produce our own XML modules that can do our work. And
 you can help by praising those that do produce good XML modules and by
 using the modules that work rather than those that don't (hint: XML::XPath
 vs XML::DOM with XML::XQL). Apart from validation, what are you missing?

True. As for praise, XML::Parser does the job for me. In this specific
case, I'll be looking for something like statusfailure/status in the
response to an XML request I send. I'd like to pull out just the section
that failed and be able to create another request from that XML chunk.
It's a little down the road, but I'm trying to plan today.

  I can't help write a validating parser, but I would be happy to help
  test it out. IMHO, more XML support would help sell perl into more
  corporate settings. Java is big into buzzwords, and XML is one of the
  biggest there is at the moment. And as we know PHBs like buzzwords, so
  that is one more point in Java's favor.
 
 Actually XML is one area where mod_perl kicks Java's butt in some ways.
 AxKit is *faster* than Cocoon. Please test and see for yourself if you
 don't believe me. And building XML based web sites with AxKit is *really*
 easy. I built modperl.sergeant.org in 10 days of spare time, including a
 content management system for the news articles (note that half of the CMS
 code is just a plain mod_perl handler). I'll stick an article online
 shortly about how the site is constructed.

When AxKit first came out, I was very excited about it but never had a
chance to play with it. And it gives me (and you I'm sure) great pride
that perl's XML app server is faster than the equivalent Java version.
;-) I hope to have a play server at home soon so that I can begin
playing with cool new toys like AxKit and A0. My experience with XML is
limited at the moment, but I'm learning quickly.

-- 
Drew Taylor
Software Engineer
OpenAir.com - Making Business a Breeze!
Open a free account today at www.openair.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Apache 1.3.14 build

2000-12-05 Thread newsreader

They say mod_perl 1.24_01 (not 1.24) is to be used with apache 1.3.14

On Tue, Dec 05, 2000 at 04:02:42PM -0600, Wang, Pin-Chieh wrote:
 I am trying to build apache v.1.3.14 with Mod_perl v. 1.24 using APACI
 I am using Perl 5.6 build 620 - the latest
 
 I ran perl Makefile.PL under mod_perl-1.24 directory
 The system created Makefile in support,regex. directories
 but terminated prematually with warning message for "Apache Version 1.3.0
 required, aborting.."
 
 Any body knows why?
 Should I go back to Apache 1.3.0?
 
 Thanks for any help
 
 PC Wang
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




RE: Apache 1.3.14 build

2000-12-05 Thread Hackett, Jonny E

I had that same problem and used mod_perl-1.24_01 and was able to compile it
without anyproblems.

-jonny

-Original Message-
From: Wang, Pin-Chieh [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 05, 2000 4:03 PM
To: '[EMAIL PROTECTED]'
Subject: Apache 1.3.14 build


I am trying to build apache v.1.3.14 with Mod_perl v. 1.24 using APACI
I am using Perl 5.6 build 620 - the latest

I ran perl Makefile.PL under mod_perl-1.24 directory
The system created Makefile in support,regex. directories
but terminated prematually with warning message for "Apache Version 1.3.0
required, aborting.."

Any body knows why?
Should I go back to Apache 1.3.0?

Thanks for any help

PC Wang


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread Matthew Kennedy

Perrin Harkins wrote:
 
 On Tue, 5 Dec 2000, Matthew Kennedy wrote:
  I've worked with both (Java 2 EE and tools like Apache::ASP/Mason).
  What people want out of an "enterprise solution" is a middle tier
  which is not tied into the presentation. When you free your process
  decisions from the presentation in that way, you can implement a B2B
  type transactions much more easily. The rationale for J2EE is already
  defined quite well in this way.
 
 Mr. Mather's Apache::PageKit module does a good job of implementing the
 model/view/controller paradigm in mod_perl.

I will check that out.

  Transaction support for your business logic is easy in J2EE. It's not
  clear how you do this in Perl?
 
 Use an RDBMS.

You don't understand that it can have nothing to do with a RDBMS. I'm
not talking about transaction control within the context of a database
within a RDBMS. As I wrote to another user on this list, say you have
two database servers and you need to implement a process which operates
on each database in order. Maybe you move an item from on to the other.
What if the second operation fails? Natually you want to roll-back to
before the operation on the first. That's what J2EE transactions are
about. See how RDMBS transactions are a different deal in this
situation?

 - Perrin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: mod_perl advocacy project resurrection

2000-12-05 Thread brian moseley

On Tue, 5 Dec 2000, Matt Sergeant wrote:

 But I'd really love to hear some rational discussion on
 transaction object support. There are open source J2EE
 implementations - would it be possible to look a porting
 the transaction management components of that to Perl?
 Would this be desirable? Personally I put all
 transaction critical stuff in the database, and rely on
 RDBMS transaction support, but I've never done J2EE, so
 I'm curious as to the advantages.

transaction management, message queuing, container managed
persistence, a naming/directory interface, a monitoring
(snmp) framework, enterprise application integration...
these are all things in j2ee and associated products that we
don't have.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: RFC: mod_perl advocacy project resurrection

2000-12-05 Thread Gunther Birznieks

I think the issue is Perl for web applications advocacy rather than 
mod_perl advocacy. If more people thought using Perl for web apps was 
cooler and easier than using PHP, then they would use Perl and then 
graduate to mod_perl when they were ready.

As it is, PHP has 1-up on CGI/Perl. PHP is FAST while still having an easy 
programming model. Having an easy programming model was Perl's claim to 
fame and why web apps fluorished in CGI/Perl. But PHP added one thing -- 
speed -- and they are taking it all away from Perl.

The problem is mod_perl is not easy. Make a CGI/Perl solution for speeding 
up CGIs EASY and you will find people migrating back from PHP to Perl. 
Attending the PHP talks at ApacheCon/Europe, if there was one thing I 
found, PHP as a language is still REALLY new. PHP4 is the first really 
professional version of PHP, PHP3 is filled with a lot of skeletons. And I 
heard people still arguing about PHP4's language merits.

Rasmus posted on BUGTRAQ the other day about some security problems with 
PHP scripts coming up (there have been several in the last week)... He 
posted that anyone running the scripts should upgrade to PHP4. Yet people 
are still finding it hard to upgrade to PHP4. So those people will have to 
go through hoops to shutdown security problems in their public domain PHP 
apps?

Larry Wall was a genius in creating a great language with ease of 
expression. But we didn't carry the torch to make it fast and easy.

By the way, I *LOVE* SpeedyCGI and mod_speedy. I forget who mentioned it to 
me at ApacheCon/Europe, but THANK YOU SO MUCH.

For those of you that have not  seen the project, please try it out. It 
makes speeding up CGI/Perl almost trivial. And it's definitely an ISPable 
solution because it plugs into Apache's CGI mechanism (non of the annoyance 
of giving plain users control over handlers).

And oh yeah, SpeedyCGI is web server independent. It works just as well on 
Netscape (which is where I had to use it on a client site).

The model is similar to FastCGI, but SpeedyCGI is trivial to setup unlike 
FastCGI which requires modification to the app.

At 09:22 AM 12/5/00 -0800, Paul wrote:

--- Stas Bekman [EMAIL PROTECTED] wrote:
.
  I see two main streams:
  1) Online zines.
  2) Conferences.

Apache.org has a whole subsection devoted to mod_perl
Any idea what it would take to get a link there from webs like tpj and
Perl.com?  I was thinking that perl.com has a nice series of articles
going for newcomers to the language, and Mark Jason-Dominus' series of
red-flag articles has certainly been worth a read; wouldn't a less
generic article series for less-new users interested in perl topics
like Apache be worth space and a link?  I've seen links to specific
high-profile uses like the Human Genome Project as Perl advocacy.
Wouldn't mod_perl be worth an ongoing link page in that right, perhaps
with discussions of sites handling thorny problems?  Or am I behind the
times on that one?

I'd even volunteer to write a few articles, though I hardly consider
myself qualified to teach anything more than the basic concepts.  I'm
still on the steep side of the learning curve for designing effective
and efficient subsites with handlers and some Embperl, but our shop has
some odd needs that mod_perl seems built-for, and I do love to talk

comments?

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Problem Building Mod_Perl 1.24_01 under AIX and gcc

2000-12-05 Thread Jens-Uwe Mager

On Tue, Dec 05, 2000 at 03:50:00PM -0600, William R. Mattil wrote:
 IBM RISC 6000 gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)
 apache_1.3.14
 mod_perl-1.24_01
 
 perl is perl-5.6.0
 
 
 mod_perl - 
 
 $ cd mod_perl-1.XX
  $ perl Makefile.PL \
  APACHE_SRC=../apache_1.3.X/src \
  DO_HTTPD=1 \
  USE_APACI=1 \
  PREP_HTTPD=1 \
  EVERYTHING=1 \
  [...]
  $ make
  $ make test
  $ make install
 $ cd apache_1.3.X
  $ ./configure \
  --prefix=/path/to/install/of/apache \
  --activate-module=src/modules/perl/libperl.a \
  [...]
  $ make
  
 results in:
 
 
 cd ..; gcc  -DAIX=42 -U__STR__ -DAIX_BIND_PROCESSOR -DMOD_PERL
 -DUSE_PERL_SSI -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE
 -fno-strict-aliasing -I/usr/local/include -DUSE_HSREGEX -DUSE_EXPAT
 -I./lib/expat-lite -DNO_DL_NEEDED `./apaci` -I.
 -I/usr/local/lib/perl5/5.6.0/aix/CORE  -lm  -o helpers/dummy
 helpers/dummy.c   -Xlinker
 -bE:/usr/local/lib/perl5/5.6.0/aix/CORE/perl.exp  -L/usr/local/lib
 /usr/local/lib/perl5/5.6.0/aix/auto/DynaLoader/DynaLoader.a
 -L/usr/local/lib/perl5/5.6.0/aix/CORE -lperl -lnsl -ldbm -ldl -lld -lm
 -lc -lbsd -lPW -liconv -bE:./modules/perl/mod_perl.exp 
 gcc: installation problem, cannot exec `cpp': No such file or directory
 gcc: file path prefix
 `/usr/local/lib/gcc-lib/E:./modules/perl/mod_perl.exp/egcs-2.91.60/'
 never used
 make: The error code from the last command is 1.

You must compile all of perl, mod_perl and apache using the same
compiler. In your case perl was compiled using the IBM C compiler, and
the perl build procedure introduces compiler flags needed for mod_perl
that are doing something completely different with gcc, causing the
confusing error message.

-- 
Jens-Uwe Mager

HELIOS Software GmbH
Steinriede 3
30827 Garbsen
Germany

Phone:  +49 5131 709320
FAX:+49 5131 709325
Internet:   [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




XML::ValidWriter - \$scaler [Was: mod_perl advocacy project resurrection]

2000-12-05 Thread barries

On Tue, Dec 05, 2000 at 05:31:49PM -0500, Drew Taylor wrote:
 

I've used XML::Checker::Parser with no big issues.

 My biggest problem with XML::Writer (and hence XML::ValidWriter) is that
 I can't write to a string, unless there is some hackish workaround.

XML::ValidWriter writes to a string if you pass in a \$scalar as the
destination:

   new
  $writer = XML::ValidWriter-new( DTD = $dtd, OUTPUT = \*FH ) ;

   Creates an XML::ValidWriter.

   The value passed for OUTPUT may be:

   a SCALAR ref
   if you want to direct output to append to a
   scalar.  This scalar is truncated whenever the
   XML::ValidWriter object is reset() or DESTROY()ed

   a file handle glob ref or a reference to an IO object
   XML::ValidWriter does not load IO.  This is the
   only mode compatible with XML::Writer.

   a file name
   A simple scalar is taken to be a filename to be
   created or truncated and emitted to.  This file
   will be closed when the XML::ValidWriter object is
   reset or deatroyed.

- Barrie

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




  1   2   >