RE: Simple question about tables [OT]
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)
"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!!!
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)
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
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
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)
[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!!!
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!!!
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)
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!!!
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
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
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
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
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
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
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!!!
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
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
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
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
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
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
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
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
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
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
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
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
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
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
--- 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
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
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
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
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
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
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
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!!!
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
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
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
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
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
-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
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
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!!!
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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]
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
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
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
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
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
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
"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
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
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
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
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
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
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
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
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
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!)
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
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
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
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
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
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
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
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)
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
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
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
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
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)
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
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
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
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
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
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
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]
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]
