Re: mod_perl Guide Patch
At 16:19 15/10/2002, Per Einar Ellefsen wrote: At 13:07 25.10.2002, Lee Goddard wrote: Well, not really a patch but a tiny contribution to an excellent guide -- Mr Beckman, I hope this is of use: On/section: guide/performance.html#Using_1_Under_mod_perl_and_be Using $|=1 Under mod_perl and Better print() Techniques Whilst the code is correct, even if it does use CGI.pm..., It might be a good idea to mention that if an external file is pulled in by the header, it seems that it has to be loaded before any output occurs. My print_html_header methods have a flag which will cause SCRIPT src and relevant LINK href URIs to be parsed, loaded and included inline. Slow but better than a poke in the eye with a sharp stick. Hello Lee, I'm sorry, but I'm not sure I understand what you mean by an external file is pulled in by the header. I understand your example, but not its relation to the section you refer to. Could you give a code example or some more information? Hello - I may have unsub'd from the list by now, so would you mind cc'ing this for me if it doesn't get through and if you think it useful? So, I simply meant that if you are trying to get $|=1 type instant output and your HTML header pulls in other files -- using script type=text/pascal src=another.doc/script or link rel='stylesheet' type='text/css' href='outside.css'/ then you will not get the expected output instantly, but only after the whole document has loaded. I guess this is because the document will not be rendered until the browser (or let's face, the IE6) has received the external files and the whole BODY. If you trying sticking a CSS/script link in the $q-html_head call in the mod_perl Guide example, you should see what I mean. Took me hours to figure it out Cheers lee
Re: mod_perl Guide Patch
Hello Lee, So, I simply meant that if you are trying to get $|=1 type instant output and your HTML header pulls in other files -- using script type=text/pascal src=another.doc/script or link rel='stylesheet' type='text/css' href='outside.css'/ then you will not get the expected output instantly, but only after the whole document has loaded. I guess this is because the document will not be rendered until the browser (or let's face, the IE6) has received the external files and the whole BODY. If you trying sticking a CSS/script link in the $q-html_head call in the mod_perl Guide example, you should see what I mean. Sure, I understand what you mean now. I'll consider it for inclusion. Thank you for your contribution. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: mod_perl Guide Patch
At 13:07 25.10.2002, Lee Goddard wrote: Well, not really a patch but a tiny contribution to an excellent guide -- Mr Beckman, I hope this is of use: On/section: guide/performance.html#Using_1_Under_mod_perl_and_be Using $|=1 Under mod_perl and Better print() Techniques Whilst the code is correct, even if it does use CGI.pm..., It might be a good idea to mention that if an external file is pulled in by the header, it seems that it has to be loaded before any output occurs. My print_html_header methods have a flag which will cause SCRIPT src and relevant LINK href URIs to be parsed, loaded and included inline. Slow but better than a poke in the eye with a sharp stick. Hello Lee, I'm sorry, but I'm not sure I understand what you mean by an external file is pulled in by the header. I understand your example, but not its relation to the section you refer to. Could you give a code example or some more information? -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: the Guide
Wouldn't it thus be simpler and more convenient for 1st times like myself if the guide download were simply the already created html pages which appear online. Frankly, hardly anyone does that. Most people refer to the guide on-line. I've used mod_perl for years, referred to the guide frequently, and never downloaded it. If you have to work over a slow link I can understand why you might want a local copy, but a quick wget command can mirror it all for you pretty easilly. People usually only download the CPAN package if they're planning to do some hacking on it. Mentioning the module dependency in the text next to the download link is probably a good idea, and offering a .tgz of all the generated HTML files as well as the PDF, but I think you may be the first to request such a thing. It's hard enough to install mod_perl itself. Why add an extra burden for the manual also. There is plenty of documentation on building and working with mod_perl included in the standard mod_perl package. The guide is in addition to that documentation. - Perrin
Re: mod_perl guide HELP -- Full transcript
[Moving the discussion where it belongs to: the mod_perl list] On Fri, 3 Aug 2001, christopher sagayam wrote: please ignore if my earlier email was clear enough what's the value of PERL and FULLPERL var in the generated Makefile? e.g. on my machine: PERL = /usr/bin/perl FULLPERL = /usr/bin/perl if it's not /tmp/chrisperl/bin/perl than you have an issue with Perl, and not mod_perl. # /tmp/chrisperl/bin/perl Makefile.PL Configure mod_perl with ../apache_1.3.20/src ? [y] y Shall I build httpd in ../apache_1.3.20/src for you? [y] y Appending mod_perl to src/Configuration Using config file: /tmp/dump/mod_perl-1.26/src/Configuration Creating Makefile + configured for Solaris 280 platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o perl_module uses ConfigStart/End + mod_perl build type: OBJ + setting up mod_perl build environment + id: mod_perl/1.26 + id: Perl/5.00503 (solaris) [perl] chris - Original Message - From: christopher sagayam [EMAIL PROTECTED] To: Stas Bekman [EMAIL PROTECTED] Sent: Friday, August 03, 2001 11:19 AM Subject: Re: mod_perl guide HELP Thanks a lot for your response but what happens is when it reports + adding selected modules o perl_module uses ConfigStart/End + mod_perl build type: OBJ + setting up mod_perl build environment + id: mod_perl/1.26 + id: Perl/5.00503 (solaris) [perl] it reports the old version namely 5.00503 whereas the new perl is version 5.6 # /tmp/chrisperl/bin/perl -v This is perl, v5.6.1 built for sun4-solaris Copyright 1987-2001, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. please help again ? Thanks chris - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: christopher sagayam [EMAIL PROTECTED] Sent: Friday, August 03, 2001 11:09 AM Subject: Re: mod_perl guide HELP yOn Fri, 3 Aug 2001, christopher sagayam wrote: I want the modperl and apache installation to recognize the perl installed at /tmp/newperl/bin/perl and not the default /usr/bin/perl so what configuration parameteres i must pass to perl Makefile.PL You should build mod_perl with your other Perl % /tmp/newperl/bin/perl Makefile.PL ... _ 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://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _ 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://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_perl guide corrections: in uris
At 02:54 12/02/2001 +0100, Marc Lehmann wrote: Stas told me to forward my mail to the list, since there was a large discussion about it. Since I now see that this seems to have been a kind of dispute and not an ommision I'll provide references to the standards below. - Forwarded message from Marc Lehmann [EMAIL PROTECTED] - in http://perl.apache.org/guide/browserbugs.html I read: Preventing QUERY_STRING from getting corrupted because of entity key names: http://my.site.com/foo.pl?foo=barreg=foobar, then some browsers will interpret reg as an SGML entity This claims this is a browser bug, which it isn't. Browsers are perfectly fine to interpret the reg as an entity when you embed this in the html source unquoted. I don't think so. The browser would be right to treat reg; as an entity, not reg. If it had proper heuristics for dealing with poor HTML, it'd detect that there is no ; in sight for the next n chars, or that reg= isn't the start of an entity it knows about, and it would treat the as a literal. However, I agree that people should try their best to write proper html. If the above url appeared in a link it should be encoded as http://my.site.com/foo.pl?foo=baramp;reg=foobar. I find that a lot of developers don't care the least about the html they output because they somehow despise it. Think twice: take out the html, what's left of your site ? XHTML clearly forbids such wrong constructs (won't even parse if you get it wrong) and that's cool. It's like use strict for HTML. -- robin b. In which level of metalanguage are you now speaking?
Re: mod_perl guide corrections: in uris
On Mon, Feb 12, 2001 at 03:13:55AM +0100, Robin Berjon [EMAIL PROTECTED] wrote: I don't think so. The browser would be right to treat reg; as an entity, not reg. But why? It's not HTML in the first place, so expecting from clients to interpret it in one way or another is not sensible. If it had proper heuristics for dealing with poor HTML, it'd detect that there is no ; in sight for the next n chars, or that reg= isn't While one might rgue that clients should apply heuristics, given the large amount of borken html out there, one has to remember that the source for this broken html WAS sloppy html parsers with heuristics. If netscape and mosaic had flagged syntax errors nobody would expect browsers to implement heuristics today :( However, I agree that people should try their best to write proper html. If Especially since you can only choose between theoretically incorerct and in practise sometimes not working AND theoretically correct and working alway sin practise I think the choise should be clear ;) somehow despise it. Think twice: take out the html, what's left of your site ? XHTML clearly forbids such wrong constructs (won't even parse if you get it wrong) and that's cool. It's like use strict for HTML. Which is exactly my point ;) Implying this is a browser bug will only make more people insist on outputting "correct" code. After all, the clients must be fixed ;- -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: mod_perl guide corrections: in uris
At 03:26 12/02/2001 +0100, Marc Lehmann wrote: On Mon, Feb 12, 2001 at 03:13:55AM +0100, Robin Berjon [EMAIL PROTECTED] wrote: I don't think so. The browser would be right to treat reg; as an entity, not reg. But why? It's not HTML in the first place, so expecting from clients to interpret it in one way or another is not sensible. Either a client has heuristics to deal with broken stuff or it hasn't. If it does, I'd expect it to go the whole way on a simplistic case as the one above. If it had proper heuristics for dealing with poor HTML, it'd detect that there is no ; in sight for the next n chars, or that reg= isn't While one might rgue that clients should apply heuristics, given the large amount of borken html out there, one has to remember that the source for this broken html WAS sloppy html parsers with heuristics. If netscape and mosaic had flagged syntax errors nobody would expect browsers to implement heuristics today :( It's a chicken and egg problem. See how Netscape 6 / Mozilla is being bashed by designers out there. They all think it's a broken browser because it won't take their broken HTML. It tries hard (if you don't put a doctype, or put an old one) to emulate Netscape 4 brokenness, but it can't go all the way. As a result all those people are not using it, and are telling everyone not to use it. When you think that most of the time those people are considered "experts" in HTML/the web by others around them you can tell that a browser won't get accepted if those braindead pseudo-experts aren't happy with it. The only way out is careful education, and that's going to take time. However, I agree that people should try their best to write proper html. If Especially since you can only choose between theoretically incorerct and in practise sometimes not working AND theoretically correct and working alway sin practise I think the choise should be clear ;) True. It's really easy to produce html that does whatever you want and is correct. And is accessible. The main argument I use when convincing people (and I have to do that a lot) is forward compatibility. If it's correct now it'll always be. Today's heuristics may disappear with the next browser version. somehow despise it. Think twice: take out the html, what's left of your site ? XHTML clearly forbids such wrong constructs (won't even parse if you get it wrong) and that's cool. It's like use strict for HTML. Which is exactly my point ;) Implying this is a browser bug will only make more people insist on outputting "correct" code. After all, the clients must be fixed ;- We are in agreement :-) That isn't a browser bug and should be removed from the list. -- robin b. "Windows may be pretty. And easy. But it has no depth or soul. It's like the one-night stand of operating systems. You feel cheap after using it." -- Steph, in User Friendly
Re: mod_perl guide corrections
On 14 Sep 2000, Joe Schaefer wrote: 2) Apache::Request is better than your performance numbers indicate. The problem I have with your comparison with Apache::args vs Apache::Request vs CGI is that your benchmark code isn't fair. You're comparing method calls against hash-table lookups, which is apples and oranges. To get more representative numbers, try the following code instead my $args = $q-param; # hash ref you mean parms() ? the Apache::Request::parms hash ref is tied, so there are still method calls, but less than calling params(), which does extra stuff to emulate CGI::params. parms() is going to be renamed (to something less like params()) and documented as faster than using the params() wrapper, in the next release.
Re: mod_perl guide corrections
Doug MacEachern [EMAIL PROTECTED] writes:
my $args = $q-param; # hash ref
you mean parms() ? the Apache::Request::parms hash ref is tied, so
there are still method calls, but less than calling params(), which does
extra stuff to emulate CGI::params.
I just looked at line 21 from Request.pm; it looks like $q-param() returns
the same thing as $q-parms does; but surely $q-parms is even better!
parms() is going to be renamed (to something less like params()) and
documented as faster than using the params() wrapper, in the next release.
A new libapreq release? Great news! Here's YAP for libapreq - I added Dave Mitchell's
memmem in multipart_buffer.c for better portability, and made some minor changes
to apache_request.c to eliminate some unnecessary copying. I'd be glad to send
you a url to a production server, if you'd like to see it in action.
HTH, and thanks again.
--
Joe Schaefer
[EMAIL PROTECTED]
SunStar Systems, Inc.
diff -ur libapreq-0.31/c/apache_request.c libapreq/c/apache_request.c
--- libapreq-0.31/c/apache_request.c Fri Jul 2 21:00:17 1999
+++ libapreq/c/apache_request.c Sun Sep 24 22:10:18 2000
@@ -64,8 +64,20 @@
for(x=0;str[x];x++) if(str[x] == '+') str[x] = ' ';
}
-static int util_read(ApacheRequest *req, const char **rbuf)
+static int util_read(ApacheRequest *req, char **rbuf)
{
+/* could make pointer array (LoL) to capture growth
+ * p[1] - [...\0]
+ * p[2] - [\0]
+ * p[3] - [..\0]
+ *
+ * would need hi-tech flushing routine (per string)
+ * also need a hi-tech reader. is it really worth the trouble?
+ *
+ *
+ *
+ */
+
request_rec *r = req-r;
int rc = OK;
@@ -84,9 +96,9 @@
return HTTP_REQUEST_ENTITY_TOO_LARGE;
}
- *rbuf = ap_pcalloc(r-pool, length + 1);
+ *rbuf = ap_pcalloc(r-pool, length + 1); /* can we improve this? */
- ap_hard_timeout("[libapreq] util_read", r);
+ ap_hard_timeout("[libapreq] util_parse", r);
while ((len_read =
ap_get_client_block(r, buff, sizeof(buff))) 0) {
@@ -234,56 +246,56 @@
return req;
}
-static int urlword_dlm[] = {'', ';', 0};
+/* static int urlword_dlm[] = {'', ';', 0}; */
-static char *my_urlword(pool *p, const char **line)
+char *my_urlword(ApacheRequest *req, char **line)
{
-int i;
-
-for (i = 0; urlword_dlm[i]; i++) {
- int stop = urlword_dlm[i];
- char *pos = strchr(*line, stop);
- char *res;
-
- if (!pos) {
- if (!urlword_dlm[i+1]) {
- int len = strlen(*line);
- res = ap_pstrndup(p, *line, len);
- *line += len;
- return res;
- }
- continue;
- }
+char dlm[] = ";";
+long int len;
+char *word, *dlm_ptr;
- res = ap_pstrndup(p, *line, pos - *line);
+if (! *line) { return NULL; }
- while (*pos == stop) {
- ++pos;
- }
+dlm_ptr = strpbrk(*line, dlm);
- *line = pos;
+if (!dlm_ptr) {
+ word = *line;
+ *line = NULL;
+ return word;
- return res;
+} else {
+ *dlm_ptr = '\0';
+ word = *line;
+ *line = dlm_ptr + 1;
+ return word;
}
-
-return NULL;
}
-static void split_to_parms(ApacheRequest *req, const char *data)
+static void split_to_parms(ApacheRequest *req, char *data)
{
request_rec *r = req-r;
-const char *val;
-
-while (*data (val = my_urlword(r-pool, data))) {
- const char *key = ap_getword(r-pool, val, '=');
+char dlm[] = ";";
+char *word;
+char *val;
+
+do {
+ word = my_urlword(req, data); /* modifies data */
+
+ if (!(val = strchr( word, '='))) {
+ continue; /* ignores words w/o an = sign */
+ }
+
+ *val = '\0';
+ ++val;
- req_plustospace((char*)key);
- ap_unescape_url((char*)key);
req_plustospace((char*)val);
ap_unescape_url((char*)val);
+ req_plustospace((char*)word);
+ ap_unescape_url((char*)word);
+
+ ap_table_add(req-parms, word, val);
- ap_table_add(req-parms, key, val);
-}
+} while ( data ) ;
}
@@ -293,7 +305,8 @@
int rc = OK;
if (r-method_number == M_POST) {
- const char *data, *type;
+ char *data = NULL;
+ const char *type;
type = ap_table_get(r-headers_in, "Content-Type");
@@ -304,12 +317,13 @@
return rc;
}
if (data) {
- split_to_parms(req, data);
+split_to_parms(req, data);
}
+
}
if (r-args) {
- split_to_parms(req, r-args);
+ split_to_parms(req, ap_pstrdup(r-pool,r-args));
}
return OK;
@@ -439,7 +453,7 @@
}
if (r-args) {
- split_to_parms(req, r-args);
+ split_to_parms(req, ap_pstrdup(r-pool,r-args));
}
return OK;
diff -ur libapreq-0.31/c/multipart_buffer.c libapreq/c/multipart_buffer.c
--- libapreq-0.31/c/multipart_buffer.c Sat May 1 02:44:28 1999
+++ libapreq/c/multipart_buffer.c Fri Sep 22 02:14:25 2000
@@ -55,134 +55,180 @@
*
*/
+/* JS: 6/30/2000
+ * This should fix the memory allocation issues, and handle client disconnects
+ * gracefully. Comments in the code should explain what I think is going on.
+ */
+
+
#include
Re: patches to mod_proxy (was: Re: mod_perl guide corrections)
On Tue, Sep 19, 2000 at 03:24:50PM -0400, Joe Schaefer wrote: On linux, the ext2 filesystem is VERY efficient at buffering filesystem writes (see http://www.tux.org/lkml/#s9-12). If the post data is small ( I don't know what the default size is, but the FILE buffer for the tmpfile is adjustable with setvbuf) it's never written to disk. AFAIK, the only problem with this arrangement for small posts is the extra file descriptor consumed by the apache process. Yeah, I know it's fairly negligible, but I'm not sure the FILE buffer is the one that matters here. If I fwrite(), rewind() and then fread() again, AFAIK libc's stdio still translates this into real kernel write(), lseek(), read() [strace woudl be the final judge here]. From there, the kernel can be smart enough to not actually even touch the disk, but that doesn't work with e.g journaling filesystems which impose stronger sequential conditions on disk writes, or systems like BSD that do synchronous metadata updates. And in any case, you're still doing extra memory copies to and from kernel space. If it was hard to do it otherwise i'd agree with you, but it sounds so simple to keep it in a memory buffer when it's under 16k or some similar limit, that I just think it's much more "obviously right" to do it that way. -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
Re: patches to mod_proxy (was: Re: mod_perl guide corrections)
Roger Espel Llima [EMAIL PROTECTED] writes: On Tue, Sep 19, 2000 at 03:24:50PM -0400, Joe Schaefer wrote: On linux, the ext2 filesystem is VERY efficient at buffering filesystem writes (see http://www.tux.org/lkml/#s9-12). If the post data is small ( I don't know what the default size is, but the FILE buffer for the tmpfile is adjustable with setvbuf) it's never written to disk. AFAIK, the only problem with this arrangement for small posts is the extra file descriptor consumed by the apache process. Yeah, I know it's fairly negligible, but I'm not sure the FILE buffer is the one that matters here. If I fwrite(), rewind() and then fread() again, AFAIK libc's stdio still translates this into real kernel write(), lseek(), read() [strace woudl be the final judge here]. From there, the kernel can be smart enough to not actually even touch the disk, but that doesn't work with e.g journaling filesystems which impose stronger sequential conditions on disk writes, or systems like BSD that do synchronous metadata updates. And in any case, you're still doing extra memory copies to and from kernel space. If it was hard to do it otherwise i'd agree with you, but it sounds so simple to keep it in a memory buffer when it's under 16k or some similar limit, that I just think it's much more "obviously right" to do it that way. Sounds good- thanks for the details. How about making a lower limit (for switching from a memory buffer to tmpfile) configurable? Any thoughts on what the directive should be called? -- Joe Schaefer [EMAIL PROTECTED] SunStar Systems, Inc.
Re: mod_perl guide corrections
[EMAIL PROTECTED] writes: What if you wanted the functionality of the fase handlers before and after the loading of the file.. Could this also be accomplished by proper use of configuration statements in http.conf? Right now I do not think so, so getting the child tied up for the time of the upload I take for granted. I'm not quite sure what your driving at. Let me see if I can describe how things work now, and what I'm trying to accomplish with the patch. Setup: A = mod_proxy enabled front-end server; keepalives enabled delivers static content (images, stylesheets, etc) proxies dynamic content B = mod_perl server; responsible for dynamic content; keepalives disabled Z = browser Event: 1) Z requests a dynamic page from A. Z -GET 1.1- A -PROXY- B -PROXY- A -CLOSE- Z The current mod_proxy CLOSES the connection from A to Z, even if Z requests keepalives, and A implements them. This is bad since subsequent requests for static content (images/stylesheets,etc.) will require a new connection. The patch should prevent mod_proxy from forcibly closing the A-Z connection. 2) Z posts form data that will ultimately be handled by B. Z -POST- A -PROXY- B Currently, mod_proxy opens the connection to B as soon as it determines B is the ultimate destination. As the POST data is read from Z to A, it is passed along directly to B. This will tie up both A and B if the A-Z connection is slow and/or the post data is huge. The patch makes mod_proxy buffer the post data in a temp file by setting the (new) ProxyPostMax directive to a positive number. If the Content-Length header supplied by Z is greater than this number, mod_proxy rejects the post request. Once the post data has been uploaded from Z-A, the patched mod_proxy opens the connection to B and delivers the POST data directly from the temp file. That's what I'm trying to accomplish with the mod_proxy patch. I've done only minimal testing on http requests; https is NOT implemented at all. I'd need something like this implemented, since I use mod_perl for authenticating "POSTers". In my case the POST data must be processed by the mod_perl server. Any help/suggestions are welcome and appreciated! -- Joe Schaefer [EMAIL PROTECTED] SunStar Systems, Inc.
Re: mod_perl guide corrections
On 14 Sep 2000, Joe Schaefer wrote: Stas, http://perl.apache.org/guide/scenario.html#Buffering_Feature ... There is no buffering of data uploaded from the client browser to the proxy, thus you cannot use this technique to prevent the heavy mod_perl server from being tied up during a large POST such as a file upload. Falling back to mod_cgi seems to be the best solution for these specific scripts whose major function is receiving large amounts of upstream data. ... What if you wanted the functionality of the fase handlers before and after the loading of the file.. Could this also be accomplished by proper use of configuration statements in http.conf? Right now I do not think so, so getting the child tied up for the time of the upload I take for granted. Of course I have been mistaken several other times. Arnold
RE: ANNOUNCE: Guide = Book
well, I spent a coupla days trying to recall my first days in mod_perl and I remembered a few pitfalls not in the Guide. Since I have seen other users on this list encounter the same questions, I thought I'd bring them up... 1) getting mod_perl RPMs to work under Linux 2) figuring out exactly what things are needed to sucessfully compile apache/mod_perl from source (not necessarily Linux specific). I'll explain... Being (more then than now) slightly RedHat/RPM impaired, I wanted to have a mod_perl enabled Apache server. If you install the Apache RPM boom, apache is working. Now, there is a mod_perl RPM as well (on my 5.2 discs, that is). However, when I installed it went about the guide's "How do I know mod_perl is working" stuff, no luck. It eventually led me to installing from both apache and mod_perl source from CPAN (the right thing to do). Anyway, being new to the whole sys admin stuff, it took me the better part of a day to figure out that I needed gcc, make, glibc or whatever to be able to compile the stuff (picture, installing gcc RPM, trying to compile, installing glibc RPM, trying to compile...). I still am not sure what exact packages are necessary, eventually I just installed everything that looked appropriate. At any rate, I have seen others struggle with installing apache and mod_perl from the RPM, having no luck, then trying to compile from the RPM source, still having trouble. My advice to these folks is to abandon the RPM and go to CPAN. I don't know of anyone who has managed to do this successfully (but I love to hear about it). Occasionally, those people also don't have the right packages installed necessary to compile from source. I pretty much tell them I just started installing stuff and eventually it worked, but I wished I could offer them a difinitive list. Thus, it might be worth mentioning that RPMs are a _bad_ idea for those just getting into mod_perl. That is, unless others have been more successful that I... Comments? --Geoff -Original Message- From: Stas Bekman [SMTP:[EMAIL PROTECTED]] Sent: Friday, October 01, 1999 7:21 AM To: mod_perl list Subject: ANNOUNCE: Guide = Book Hi, I've started to work on converting the mod_perl Guide into a mod_perl introduction book. The publisher is O'Reilly(R). Many thanks to Doug for making this a reality!!! It's a big proud for me to work for this great publisher! The book will be based on the guide. I'll add many working code examples and detailed explanations of the code. This book is very unique since it's based on many little and big pieces of information contributed by hundreds of people on the list, many even don't know that they contributed, as I quietly save the emails and read them to find yet unanswered questions and answers to them. (this reminds me that I have to update the contribution list at the guide :) This is your chance to make the book the way you want. So if you didn't read the guide yet, take a look. Tell me what's wrong, what's good. What parts are really missing. If you have code snippets to contribute -- it would help a lot. Just try to remember what things you have had to learn the hard way, and you wish it was written somewhere. I get many letter saying "where have your guide been 1 year ago when we had so many questions and no answers!". So please help me to identify those unanswered questions and provide the answers. Before the stuff is written you can make an influence! Please note that this is a complementary book to the Eagle book, not a rival to this wonderful book! I've enjoyed every moment of reading it. I'm going thru this book to make sure I wouldn't duplicate parts of it. So when you make suggestions please remember that the material you are going to suggest might be already covered in the Doug and Lincoln's book. And wish me good luck :) P.S. The guide will stay online as it is, and will be updated as I get more contributions from you, so don't stop these coming. ___ Stas Bekman mailto:[EMAIL PROTECTED]www.singlesheaven.com/stas Perl,CGI,Apache,Linux,Web,Java,PC at www.singlesheaven.com/stas/TULARC www.apache.org www.perl.com == www.modperl.com || perl.apache.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
