RE: CGI::Delete for Apache::Request
say, rfc's are good for something after all ;) ok, form_data() it is!
Re: Q: DBMS update framework for use within Apache::DBI?
At 12:16 PM 5/17/00 -0600, Bruce W. Hoylman wrote: Ciao! I am searching for the makings of a framework built around or within mod_perl/Apache::DBI that supports the consistent update of a record within a database. Primarily I am wanting to ensure read/write integrity between database accesses by the web client, meaning I wish to ensure the record about to be updated meets the following criteria: 1) It exists. If it does not, perform an insert instead 2) If it exists, check that it is unchanged from the time the web client first retrieved it for update. If it has changed, throw an exception. I do not want a "last update wins" situation. This first criteria seems a tad odd to me. What business scenario is there for this? To me, when a user issues an update they expect that the record exists. In a way, if the record does NOT exist, then you are really going against your rule #2. That is, if they issue an update and the record no longer exists, then that is also a change to the record that someone did (a deletion) and you are effectively overriding someone elses deletion. This is being done in an mod_perl/embperl/Apache::DBI environment. Suggestions or pointers to additional information would be greatly appreciated. Peace. An application which implements #2 and is accelerated when used with mod_perl (Apache::Registry) and Apache::DBI is our latest version of WebDB. You may download a copy at http://www.extropia.com/ and click on download button at the top upper right)... If you want to read about it, the docs are located at http://www.extropia.com/docs/webdb/. Actually it was all generated using Stas Bekman's mod_perl guide generator (except using my pods instead of Stas's mod_perl guide pods) The WebDB will do #2 for you and, in fact, allows configuring the strategy of updates... eg you can choose to check all fields for changes, a subset of fields for changes, or just "key fields" for changes... similar to the PowerBuilder DataWindow model of handling client-server updates. This is done through the use of Extropia::DataSource which is a library that abstracts this stuff away. By default, WebDB is distributed to be configured to use Extropia::DataSource::File, but you just need to take out the file specific stuff from the config and then replace -TYPE = 'File' with -TYPE = "DBI" and add -DSNAME = 'dbi:yourdatabase etc..." and you are pretty much off and running. So the caveat is that the app is configured by default to work on any CGI/Perl environment. But it has been architected to take advantage of mod_perl's benefits (eg Apache::DBI) by just changing config parameters in the setup file. Since all the new extropia apps follow this common architecture, we have documented the mod_perl specific tuning issues in the Advanced Chapter of the Extropia Apps Guide (a supplement to the WebDB Guide) located at http://www.extropia.com/docs/extropia_app/ If you don't like WebDB itself and need to write your own logic, then you may want to just use Extropia::DataSource by itself (which implements the logic you want as an object but no CGI workflow exists around it). The documentation and code for that set is located at http://www.extropia.com/ExtropiaObjects/ Hope this helps, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: converting CGI scripts to mod_perl and memory use...
On Wed, 17 May 2000, Doug MacEachern wrote: On Wed, 17 May 2000, Dave DeMaagd wrote: I'm in the midst of converting a script I wrote in a CGI environment to mod_perl (using Apache::Registry). The scripts are running fine (after a little tweaking to get rid of globals and whatnot), but I am still looking for more ways to keep memory consumption under control, and for ways to check to see /where/ it's going out the window when it is. this message from last night was intended to remind of one way to do that.. Date: Tue, 16 May 2000 23:13:19 -0700 (PDT) From: Doug MacEachern [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [ANNOUNCE] B-Size-0.04 if you're not familar with B::Size, it was written a while back to answer the question 'why are my httpds so damn BIG?' there are hooks in Apache::Status to measure the size of global/lexical variables and the syntax tree. this is a debugging/educational module, for best results, run httpd in -X mode. and, do not enable on a production server, the code to measure the syntax tree can burn lots of cpu. And as usual the link: http://perl.apache.org/guide/performance.html#Measuring_the_Memory_Usage_of_Su _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
writing code that works on machines with or without mod_perl
modperlers,
does it make sense if i put some mod_perl specific codes inside
an eval() so that the code runs on machines that have or haven't
mod_perl installed?
eval 'MOD_PERL_CODE' if $ENV{MOD_PERL};
use Apache ();
my $r = Apache-request;
...
MOD_PERL_CODE
if i don't do so, perl will complain about Apache is not installed
on machines that doesn't have mod_perl installed.
kenneth
Re: writing code that works on machines with or without mod_perl
On Thu, 18 May 2000, Kenneth Lee wrote:
modperlers,
does it make sense if i put some mod_perl specific codes inside
an eval() so that the code runs on machines that have or haven't
mod_perl installed?
eval 'MOD_PERL_CODE' if $ENV{MOD_PERL};
use Apache ();
my $r = Apache-request;
...
MOD_PERL_CODE
Better still:
eval {
die unless $ENV{MOD_PERL};
require Apache;
my $r = $Apache-request;
...
};
Then you've got no (at least much less than the above) run-time overhead.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: writing code that works on machines with or without mod_perl
arggg... i was sticked to "use" instead of "require"...
but how about if i've to import something?
Matt Sergeant wrote:
On Thu, 18 May 2000, Kenneth Lee wrote:
modperlers,
does it make sense if i put some mod_perl specific codes inside
an eval() so that the code runs on machines that have or haven't
mod_perl installed?
eval 'MOD_PERL_CODE' if $ENV{MOD_PERL};
use Apache ();
my $r = Apache-request;
...
MOD_PERL_CODE
Better still:
eval {
die unless $ENV{MOD_PERL};
require Apache;
my $r = $Apache-request;
...
};
Then you've got no (at least much less than the above) run-time overhead.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: writing code that works on machines with or without mod_perl
i know that, but it doesn't work if i use "use", since the block
will be eval()'d at compile time:
eval {
die unless $ENV{MOD_PERL};
use Apache::Constants qw(:common);
...
};
it complains if Apache::Constants is not installed.
Matt Sergeant wrote:
On Thu, 18 May 2000, Kenneth Lee wrote:
arggg... i was sticked to "use" instead of "require"...
but how about if i've to import something?
perldoc -f use
Re: writing code that works on machines with or without mod_perl
On Thu, 18 May 2000, Kenneth Lee wrote:
i know that, but it doesn't work if i use "use", since the block
will be eval()'d at compile time:
eval {
die unless $ENV{MOD_PERL};
use Apache::Constants qw(:common);
...
};
it complains if Apache::Constants is not installed.
Since you didn't read the docs, here they are (relevant bit highlighted):
% perldoc -f use
=item use Module LIST
=item use Module
=item use Module VERSION LIST
=item use VERSION
Imports some semantics into the current package from the named module,
generally by aliasing certain subroutine or variable names into your
package. It is exactly equivalent to
BEGIN { require Module; import Module LIST; }
^^^
except that Module Imust be a bareword.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: passing Apache::File to XS code that expects FILE *?
"DM" == Doug MacEachern [EMAIL PROTECTED] writes: DM On Wed, 17 May 2000, Matt Sergeant wrote: Well, this may be true, but if you load IO::File before startup then it's not too big a deal... DM but it still adds a great deal of bloat to the server. and it's oo DM interface, while very slick, adds quite a bit of runtime overhead, turn DM the sugar sour imo. In an embedded environment like mod_perl, then how do you suggest to deal with the dangling file handles problem? That is, I'm processing a file or two, and some error occurs. In a normal perl program, I'd exit or return out and then when the program terminates, it automagically closes all the files. In mod_perl, the auto-close doesn't happen until much later. With the OO interface, when the handle goes out of scope, such as a function call return, the file is implicitly closed. What other mechanism do you propose to handle this situation other than IO::File? I use it all the time myself.
Re: passing Apache::File to XS code that expects FILE *?
On Thu, 18 May 2000, Vivek Khera wrote: "DM" == Doug MacEachern [EMAIL PROTECTED] writes: DM On Wed, 17 May 2000, Matt Sergeant wrote: Well, this may be true, but if you load IO::File before startup then it's not too big a deal... DM but it still adds a great deal of bloat to the server. and it's oo DM interface, while very slick, adds quite a bit of runtime overhead, turn DM the sugar sour imo. In an embedded environment like mod_perl, then how do you suggest to deal with the dangling file handles problem? That is, I'm processing a file or two, and some error occurs. In a normal perl program, I'd exit or return out and then when the program terminates, it automagically closes all the files. In mod_perl, the auto-close doesn't happen until much later. With the OO interface, when the handle goes out of scope, such as a function call return, the file is implicitly closed. What other mechanism do you propose to handle this situation other than IO::File? I use it all the time myself. use Apache; use Fcntl qw/:DEFAULT :flock/; my $fh = Apache-gensym(); sysopen($fh, "file", O_RDONLY) || die "Can't open: $!"; flock($fh, LOCK_SH) || die "Can't lock: $!"; ... when $fh goes out of scope it's closed and unlocked. Also see the guide section on exception handling. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: passing Apache::File to XS code that expects FILE *?
On Thu, 18 May 2000, Vivek Khera wrote:
"DM" == Doug MacEachern [EMAIL PROTECTED] writes:
DM On Wed, 17 May 2000, Matt Sergeant wrote:
Well, this may be true, but if you load IO::File before startup then it's
not too big a deal...
DM but it still adds a great deal of bloat to the server. and it's oo
DM interface, while very slick, adds quite a bit of runtime overhead, turn
DM the sugar sour imo.
In an embedded environment like mod_perl, then how do you suggest to
deal with the dangling file handles problem? That is, I'm processing
a file or two, and some error occurs. In a normal perl program, I'd
exit or return out and then when the program terminates, it
automagically closes all the files. In mod_perl, the auto-close
doesn't happen until much later. With the OO interface, when the
handle goes out of scope, such as a function call return, the file is
implicitly closed.
What other mechanism do you propose to handle this situation other
than IO::File? I use it all the time myself.
guide... guide... guide... :) (I'll keep you updated with the search
really soon now)
http://perl.apache.org/guide/porting.html#Filehandlers_and_locks_leakages
perl 5.6
use Symbol;
{
my $fh = gensym;
open $fh,
}
perl5.6
{
open my $fh, ...
}
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Apache::PerlVINC
I am testing the use of Apache::PerlVINC but I think I must do something wrong because I get an error on the PerlRequire statement in the following bit of httpd.conf when starting apache: - PerlModule Apache::PerlVINC VirtualHost _default_:8443 DocumentRoot /opt/ward/DocumentRoot SetEnv IDV_ENV DEV Alias /idv/ "/opt/ward/IDV/DEV/Scripts" Location /idv Options +Indexes PerlAuthzHandler Ward::Authorise SetHandler perl-script PerlHandler Apache::Registry AuthType Basic AuthName "IDV Development" AuthAuthoritative on require idvenv DEV PerlINC /opt/ward/IDV/DEV/Modules PerlVersionINC on PerlFixupHandler Apache::PerlVINC # This is line 341 PerlRequire Ward/IDV/IDVDatabase.pm /Location /VirtualHost The error I get is: Syntax error on line 341 of /opt/ward/apache/conf/httpd.conf: Can't locate Ward/IDV/IDVDatabase.pm in @INC (@INC contains: /opt/perl5/lib/5.00503/PA-RISC1.1 /opt/perl5/lib/5.00503 /opt/perl5/lib/site_perl/PA-RISC1.1 /opt/perl5/lib/site_perl . /opt/ward/apache/ /opt/ward/apache/lib/perl) at /opt/perl5/lib/site_perl/PA-RISC1.1/Apache/PerlVINC.pm line 41. --- The module I am trying to access is: /opt/ward/IDV/DEV/Modules/Ward/IDV/IDVDatabase.pm Have I misunderstood how Apache::PerlVINC works? Kees
Re: RFC: Apache::Request::Forms (or something similar)
Doug MacEachern wrote: personally, i'd like to see Apache::HTML for generating html, written in c. something simple along the lines of HTML::AsSubs, then another class to glues it and Apache::Request together that provides CGI.pm features, like 'sticky forms'. but, i haven't given that much thought. Well, I wouldn't mind doing it in C (since the raison d'etre is to be as absolutely fast lean as possible), but I don't know C. :-( -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Drew Taylor wrote: Doug MacEachern wrote: personally, i'd like to see Apache::HTML for generating html, written in c. something simple along the lines of HTML::AsSubs, then another class to glues it and Apache::Request together that provides CGI.pm features, like 'sticky forms'. but, i haven't given that much thought. Well, I wouldn't mind doing it in C (since the raison d'etre is to be as absolutely fast lean as possible), but I don't know C. :-( i suggest that most applications are going to find their bottlenecks somewhere besides simple html widget generation. it should be extremely straightforward, if maybe a bit time consuming, to write very simple, vanilla perl widget routines. that avoid the bloatfest of CGI.pm and that don't use the most esoteric features of perl like hTML::AsSubs. i think we all know that form controls are the important widgets. i challenge anyone to prove to me that you need a routine to wrap your string in b tags. i do think that doug's separation of responsibilities into classes is the right one. your widget toolkit probably shouldn't be named Apache::HTML tho, unless it's actually using the apache api in some fashion.
Re: RFC: Apache::Request::Forms (or something similar)
Drew Taylor wrote: Doug MacEachern wrote: personally, i'd like to see Apache::HTML for generating html, written in c. something simple along the lines of HTML::AsSubs, then another class to glues it and Apache::Request together that provides CGI.pm features, like 'sticky forms'. but, i haven't given that much thought. Well, I wouldn't mind doing it in C (since the raison d'etre is to be as absolutely fast lean as possible), but I don't know C. :-( I'd have no problem writing it in C, but I'm not convinced that the generality is helpful with something intended to be small and fast. That wouldn't stop us from rewriting the internals to a hypothetical Apache::HTML at some point in the future, though. I'm getting more confident about calling it Apache::Request::Form (no "s", for name similarity with CGI::Form) now. It is dependent on Apache::Request, after all, and reusing the CGI::Form name makes it look more general than it really is, not to mention any strange version skew effects CPAN.pm might introduce when people try to install things. -- Peter Haworth [EMAIL PROTECTED] "Where a computer like the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and weigh only 1 1/2 tons." -- Popular Mechanics, March 1949
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Peter Haworth wrote: I'm getting more confident about calling it Apache::Request::Form (no "s", for name similarity with CGI::Form) now. It is dependent on Apache::Request, after all, and reusing the CGI::Form name makes it look more general than it really is, not to mention any strange version skew effects CPAN.pm might introduce when people try to install things. are you still planning to subclass Apache::Request? why? what benefit do you get, if the only method from Apache::Request you need is param()? unnecessary coupling..
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote:
On Thu, 18 May 2000, Peter Haworth wrote:
I'm getting more confident about calling it
Apache::Request::Form (no "s", for name similarity with
CGI::Form) now. It is dependent on Apache::Request,
after all, and reusing the CGI::Form name makes it look
more general than it really is, not to mention any
strange version skew effects CPAN.pm might introduce
when people try to install things.
are you still planning to subclass Apache::Request? why?
what benefit do you get, if the only method from
Apache::Request you need is param()? unnecessary coupling..
I personally have code that puts a CGI.pm object in the object ($self),
which is then used for both HTML generation AND fetching params AND
cookies.
For example, I have lines like 'my $val = $self-{CGI}-param('blah')'
as well as 'my $form = $self-{CGI}-popup_menu(-name='blah', ...)'.
The effect is to emulate CGI.pm, while being leaner simpler.
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote:
On Thu, 18 May 2000, Drew Taylor wrote:
I personally have code that puts a CGI.pm object in the
object ($self), which is then used for both HTML
generation AND fetching params AND cookies.
For example, I have lines like 'my $val =
$self-{CGI}-param('blah')' as well as 'my $form =
$self-{CGI}-popup_menu(-name='blah', ...)'. The
effect is to emulate CGI.pm, while being leaner
simpler.
am i missing something..? you're actually /using/ CGI.pm
inside your new module?
No, my /CURRENT/ setup uses CGI.pm. I want to eliminate it entirely in
this new module, while not having to change any of my existing
application code. I would like to not change any lines like the ones
above when switching to the new module.
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
On Wed, 17 May 2000, Doug MacEachern wrote: personally, i'd like to see Apache::HTML for generating html, written in c. something simple along the lines of HTML::AsSubs, then another class to glues it and Apache::Request together that provides CGI.pm features, like 'sticky forms'. but, i haven't given that much thought. C seems like serious overkill for something to simply generate plain text output. How slow is making a string in perl compared to doing it in C? I can't imagine there's to much of a difference. I really think the goal should be to make Apache::Request integrated into the new CGI module (or vice versa, depends on how you look at it). -dave /*== www.urth.org We await the New Sun ==*/
Re: Q: DBMS update framework for use within Apache::DBI?
"Gunther" == Gunther Birznieks [EMAIL PROTECTED] writes: Gunther This first criteria seems a tad odd to me. What business Gunther scenario is there for this? Gunther To me, when a user issues an update they expect that the Gunther record exists. In a way, if the record does NOT exist, then Gunther you are really going against your rule #2. That is, if they Gunther issue an update and the record no longer exists, then that Gunther is also a change to the record that someone did (a Gunther deletion) and you are effectively overriding someone elses Gunther deletion. The framework is to support an intranet time tracking application. The business rules of the system dictate there are no deletions of previously submitted time ... only inserts/updates. Therefore I can say without question that an existing time record will *always* exist (a modify), albeit in a potentially 'dirty' state (rule #2). Furthermore, if a particular time period has not been accounted for, i.e. no time record has been previously submitted, a default time record will be presented for modification, and subsequent submission (an insert). This is seamless to the client requesting the period. If there is no default time record available, then a 0-hour time record is presented for modification/submission (also an insert). Gunther An application which implements #2 and is accelerated when Gunther used with mod_perl (Apache::Registry) and Apache::DBI is Gunther our latest version of WebDB. You may download a copy at Gunther http://www.extropia.com/ and click on download button at Gunther the top upper right)... Thank you for the pointer. I will *gleefully* investigate its offerings. | Hope this helps, | Gunther I'll let you know ... Peace.
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Drew Taylor wrote: No, my /CURRENT/ setup uses CGI.pm. I want to eliminate it entirely in this new module, while not having to change any of my existing application code. I would like to not change any lines like the ones above when switching to the new module. ah, ok. bumming. i suggest that instead of subclassing Apache::Request, you write the following set of classes: 1) html widget class 2) sticky forms class - use html widget class, take $r or $q as param 3) "wrapper" class - gives you the CGI.pm interface, uses sticky forms class, takes $r or $q as param this would give us the best of both worlds: you get a plug-in replacement for CGI.pm, we get a set of classes that aren't tightly coupled to each other. by keeping the sticky forms class and wrapper class separate, you allow people who just want sticky forms to get that, and people who want the whole ungodly CGI.pm interface to get that.
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote: i suggest that instead of subclassing Apache::Request, you write the following set of classes: 1) html widget class 2) sticky forms class - use html widget class, take $r or $q as param 3) "wrapper" class - gives you the CGI.pm interface, uses sticky forms class, takes $r or $q as param What do you define the difference to be between #1 and #2? All I need is sticky forms - primarily the popup_menu(). If HTML widgets are b(), td(), etc, then we didn't plan on creating those. Forms is the main point of this module. this would give us the best of both worlds: you get a plug-in replacement for CGI.pm, we get a set of classes that aren't tightly coupled to each other. by keeping the sticky forms class and wrapper class separate, you allow people who just want sticky forms to get that, and people who want the whole ungodly CGI.pm interface to get that. Now that makes sense, in that it is more generic in nature. After all, I would hope that this will be a useful module to many people, not just Peter and I. When we get some time, Peter and I should sit down and try to come up with a v.01 API. Of course, all thoughts would be welcome. The whole module is beginning to coalesce more in my mind after all this discussion. :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote: On Thu, 18 May 2000, Autarch wrote: C seems like serious overkill for something to simply generate plain text output. How slow is making a string in perl compared to doing it in C? I can't imagine there's to much of a difference. pretty slow if you build a string using .= instead of using smarter methods, like pushing strings onto an array and then joining it. I didn't know joining array elements was faster. How much slower is using the .= operator rather than join "\n", @array? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Drew Taylor wrote:
What do you define the difference to be between #1 and
#2? All I need is sticky forms - primarily the
popup_menu(). If HTML widgets are b(), td(), etc, then
we didn't plan on creating those. Forms is the main
point of this module.
well the function that creates a popup menu is different
than the function that enables stickiness for a particular
instance of a popup menu. how's this for pseudo code:
--
package FormWidget;
sub popup_menu
{
# generate the html for a popup menu
}
package StickyForm;
my $pm1 = FormWidget::popup_menu('pm1', $r-param('pm1'));
my $pm2 = FormWidget::popup_menu('pm2', $r-param('pm2'));
--
obviously there is a lot more to making forms sticky than
that. but you get the gist of the general separation of
responsibilities.
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, brian moseley wrote:
i suggest that instead of subclassing Apache::Request, you
write the following set of classes:
1) html widget class
2) sticky forms class - use html widget class, take $r or $q
as param
3) "wrapper" class - gives you the CGI.pm interface, uses
sticky forms class, takes $r or $q as param
this would give us the best of both worlds: you get a
plug-in replacement for CGI.pm, we get a set of classes that
aren't tightly coupled to each other. by keeping the sticky
forms class and wrapper class separate, you allow people who
just want sticky forms to get that, and people who want the
whole ungodly CGI.pm interface to get that.
#1 exists in the new CGI
#2 could be integrated with the new CGI with some amount of effort (though
I doubt it would be huge). Right now the sticky forms aspect works by
having the form generating object call $self-param to set defaults. If
this were changed to call $self-{state}-param and have what's in state
be either a CGI or Apache::Request object you'd be all set.
#3 is the new CGI
I really don't think we need yet another module doing what CGI does. The
people who've worked on the new version have done a very good job of
addressing the memory and speed concerns people had about the current
monolothic version. I think its much better to extend their work than to
redo it.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Want to work at a Game company?
INTERNET DEVELOPER If you like the idea of working with unique, talented people and wearing jeans and a t-shirt to work, you're just the person we're looking for. Origin is a long-standing leader in the PC-gaming industry, and an acclaimed pioneer in the online gaming genre. We create Virtual Worlds that set the standard for interactive entertainment. We're currently searching for an Internet Developer to assist in the creation and maintenance of Internet applications and to support the creation of programming that will be compelling and interactive, enticing people to enter and explore our worlds with a focus on building and strengthening our relationships with the visitor/user-community. Additionally, to assist in high-level coding during HTML production/implementation and identify new advanced programming technologies for web site development. Qualified candidates should have: QUALIFICATIONS: · Proficient with Perl and SQL. · Experience with Internet tools. · Must be able to write and implement JavaScript and HTML. · Must understand SQL and demonstrate query writing ability. · Must possess an understanding of server administration. · Computer science degree or 2-3 years Internet programming experience desired. · The ability to multi-task in a fast paced environment, thrive in a team atmosphere and effectively work with all levels of mgmt. Located in the scenic hills of Northwest Austin, we offer a unique and casual work environment along with competitive salaries and a comprehensive benefits package. Origin offers challenging projects, excellent opportunities for advancement, and the freedom to be as creative as you can possibly be. At our facility, you will find an on-site fitness-center, café, free video games, pets and more. For immediate consideration, please send resume and salary requirements to: Origin Systems-Human Resources, 5918 W. Courtyard Drive, Austin, TX 78730 or fax to 512-346-7905 or email [EMAIL PROTECTED] No phone calls please. We are an equal Opportunity Employer.
Re: Want to work at a Game company?
Is this the proper forum for this posting? "Graf, Chris" wrote: INTERNET DEVELOPER If you like the idea of working with unique, talented people and wearing jeans and a t-shirt to work, you're just the person we're looking for. Origin is a long-standing leader in the PC-gaming industry, and an acclaimed pioneer in the online gaming genre. We create Virtual Worlds that set the standard for interactive entertainment. We're currently searching for an Internet Developer to assist in the creation and maintenance of Internet applications and to support the creation of programming that will be compelling and interactive, enticing people to enter and explore our worlds with a focus on building and strengthening our relationships with the visitor/user-community. Additionally, to assist in high-level coding during HTML production/implementation and identify new advanced programming technologies for web site development. Qualified candidates should have: QUALIFICATIONS: · Proficient with Perl and SQL. · Experience with Internet tools. · Must be able to write and implement JavaScript and HTML. · Must understand SQL and demonstrate query writing ability. · Must possess an understanding of server administration. · Computer science degree or 2-3 years Internet programming experience desired. · The ability to multi-task in a fast paced environment, thrive in a team atmosphere and effectively work with all levels of mgmt. Located in the scenic hills of Northwest Austin, we offer a unique and casual work environment along with competitive salaries and a comprehensive benefits package. Origin offers challenging projects, excellent opportunities for advancement, and the freedom to be as creative as you can possibly be. At our facility, you will find an on-site fitness-center, café, free video games, pets and more. For immediate consideration, please send resume and salary requirements to: Origin Systems-Human Resources, 5918 W. Courtyard Drive, Austin, TX 78730 or fax to 512-346-7905 or email [EMAIL PROTECTED] No phone calls please. We are an equal Opportunity Employer.
Re: Want to work at a Game company?
Yes it is. Doug has always encouraged mod_perl related jobs to be posted to this list. On 18-May-2000 Buddy Lee Haystack wrote: Is this the proper forum for this posting? "Graf, Chris" wrote: INTERNET DEVELOPER If you like the idea of working with unique, talented people and wearing jeans and a t-shirt to work, you're just the person we're looking for. Origin is a long-standing leader in the PC-gaming industry, and an acclaimed pioneer in the online gaming genre. We create Virtual Worlds that set the standard for interactive entertainment. We're currently searching for an Internet Developer to assist in the creation and maintenance of Internet applications and to support the creation of programming that will be compelling and interactive, enticing people to enter and explore our worlds with a focus on building and strengthening our relationships with the visitor/user-community. Additionally, to assist in high-level coding during HTML production/implementation and identify new advanced programming technologies for web site development. Qualified candidates should have: QUALIFICATIONS: · Proficient with Perl and SQL. · Experience with Internet tools. · Must be able to write and implement JavaScript and HTML. · Must understand SQL and demonstrate query writing ability. · Must possess an understanding of server administration. · Computer science degree or 2-3 years Internet programming experience desired. · The ability to multi-task in a fast paced environment, thrive in a team atmosphere and effectively work with all levels of mgmt. Located in the scenic hills of Northwest Austin, we offer a unique and casual work environment along with competitive salaries and a comprehensive benefits package. Origin offers challenging projects, excellent opportunities for advancement, and the freedom to be as creative as you can possibly be. At our facility, you will find an on-site fitness-center, café, free video games, pets and more. For immediate consideration, please send resume and salary requirements to: Origin Systems-Human Resources, 5918 W. Courtyard Drive, Austin, TX 78730 or fax to 512-346-7905 or email [EMAIL PROTECTED] No phone calls please. We are an equal Opportunity Employer. -- Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems Lisa: Remember, Dad. The handle of the Big Dipper points to the North Star. Homer: That's nice, Lisa, but we're not in astronomy class. We're in the woods. The Call of the Simpsons
RE: Want to work at a Game company?
This was the default posting from HR. I should have thrown in the mod_perl requirement when sending to this list. All of our Perl is mod_perl, but HR didn't want to scare anyone away who might have been a good Perl programmer, but had never used mod_perl before (if it's possible to be good without using it). I know that most people on this list already have good jobs that they love, so maybe it isn't the best place to find someone. I am hoping to support any members of our community who feel like they could have more fun at work. I apologize for the spam. -Original Message- From: Jason Bodnar [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 18, 2000 12:00 PM To: Buddy Lee Haystack Cc: [EMAIL PROTECTED]; Graf, Chris Subject:Re: Want to work at a Game company? Yes it is. Doug has always encouraged mod_perl related jobs to be posted to this list. On 18-May-2000 Buddy Lee Haystack wrote: Is this the proper forum for this posting? "Graf, Chris" wrote: INTERNET DEVELOPER If you like the idea of working with unique, talented people and wearing jeans and a t-shirt to work, you're just the person we're looking for. Origin is a long-standing leader in the PC-gaming industry, and an acclaimed pioneer in the online gaming genre. We create Virtual Worlds that set the standard for interactive entertainment. We're currently searching for an Internet Developer to assist in the creation and maintenance of Internet applications and to support the creation of programming that will be compelling and interactive, enticing people to enter and explore our worlds with a focus on building and strengthening our relationships with the visitor/user-community. Additionally, to assist in high-level coding during HTML production/implementation and identify new advanced programming technologies for web site development. Qualified candidates should have: QUALIFICATIONS: · Proficient with Perl and SQL. · Experience with Internet tools. · Must be able to write and implement JavaScript and HTML. · Must understand SQL and demonstrate query writing ability. · Must possess an understanding of server administration. · Computer science degree or 2-3 years Internet programming experience desired. · The ability to multi-task in a fast paced environment, thrive in a team atmosphere and effectively work with all levels of mgmt. Located in the scenic hills of Northwest Austin, we offer a unique and casual work environment along with competitive salaries and a comprehensive benefits package. Origin offers challenging projects, excellent opportunities for advancement, and the freedom to be as creative as you can possibly be. At our facility, you will find an on-site fitness-center, café, free video games, pets and more. For immediate consideration, please send resume and salary requirements to: Origin Systems-Human Resources, 5918 W. Courtyard Drive, Austin, TX 78730 or fax to 512-346-7905 or email [EMAIL PROTECTED] No phone calls please. We are an equal Opportunity Employer. -- Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems Lisa: Remember, Dad. The handle of the Big Dipper points to the North Star. Homer: That's nice, Lisa, but we're not in astronomy class. We're in the woods. The Call of the Simpsons
Confusion on Apache::DBI
All, Sorry if this question sounds stupid.. but I am new to mod_perl and Apache::DBI.. I have successfully installed Apache Server 1.3.12 and mod_perl 1.24 and Apache::DBI 0.87 on Solaris 2.7. And I have tested all successfully... But confusion arised when I created a startup.pl file and tried to initiate DB connection in startup.pl file using 'connect_on_init' from Apache::DBI As I understood, if you have 'connect_on_init' in startup file, you have preloaded DB handle when first request comes in. And you don't need to open new db connection... But if I check the error_log file, I still have entry saying something like following: 10803 Apache::DBI need ping: yes 10803 Apache::DBI new connect to 'DatabaseNameUsernamePasswordAutoCommit=1PrintError=1' 10803 Apache::DBI disconnect (overloaded) And I will get this for first 4-5 request but after that each time I am getting 10803 Apache::DBI need ping: yes 10803 Apache::DBI already connected to 'DatabaseNameUsernamePasswordAutoCommit=1PrintError=1' 10803 Apache::DBI disconnect (overloaded) Why is that??? Shouldn't I supposed to get 'already connected to' statement right from the first request And how many open connection can I have at the same time?? As per my understood, for Apache::DBI connection pooling is based per server process. So, I guess as many server process you have, you can have db connection handle open at the same time.. AM I RIGHT HERE? Please clear my doubts on this... And thanks for your help ... Niral
RE: Want to work at a Game company?
-Original Message- From: Graf, Chris [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 18, 2000 1:09 PM To: [EMAIL PROTECTED] Subject: RE: Want to work at a Game company? This was the default posting from HR. I should have thrown in the mod_perl requirement when sending to this list. All of our Perl is mod_perl, but HR didn't want to scare anyone away who might have been a good Perl programmer, but had never used mod_perl before (if it's possible to be good without using it). I know that most people on this list already have good jobs that they love, so maybe it isn't the best place to find someone. I am hoping to support any members of our community who feel like they could have more fun at work. I apologize for the spam. no need to apologize - as Jason said, mod_perl postings are welcome. stating the mod_perl relevance up front will probably help guard against (most) questions about applicability :) --Geoff -Original Message- From: Jason Bodnar [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 18, 2000 12:00 PM To: Buddy Lee Haystack Cc: [EMAIL PROTECTED]; Graf, Chris Subject: Re: Want to work at a Game company? Yes it is. Doug has always encouraged mod_perl related jobs to be posted to this list. On 18-May-2000 Buddy Lee Haystack wrote: Is this the proper forum for this posting? "Graf, Chris" wrote: INTERNET DEVELOPER If you like the idea of working with unique, talented people and wearing jeans and a t-shirt to work, you're just the person we're looking for. Origin is a long-standing leader in the PC-gaming industry, and an acclaimed pioneer in the online gaming genre. We create Virtual Worlds that set the standard for interactive entertainment. We're currently searching for an Internet Developer to assist in the creation and maintenance of Internet applications and to support the creation of programming that will be compelling and interactive, enticing people to enter and explore our worlds with a focus on building and strengthening our relationships with the visitor/user-community. Additionally, to assist in high-level coding during HTML production/implementation and identify new advanced programming technologies for web site development. Qualified candidates should have: QUALIFICATIONS: · Proficient with Perl and SQL. · Experience with Internet tools. · Must be able to write and implement JavaScript and HTML. · Must understand SQL and demonstrate query writing ability. · Must possess an understanding of server administration. · Computer science degree or 2-3 years Internet programming experience desired. · The ability to multi-task in a fast paced environment, thrive in a team atmosphere and effectively work with all levels of mgmt. Located in the scenic hills of Northwest Austin, we offer a unique and casual work environment along with competitive salaries and a comprehensive benefits package. Origin offers challenging projects, excellent opportunities for advancement, and the freedom to be as creative as you can possibly be. At our facility, you will find an on-site fitness-center, café, free video games, pets and more. For immediate consideration, please send resume and salary requirements to: Origin Systems-Human Resources, 5918 W. Courtyard Drive, Austin, TX 78730 or fax to 512-346-7905 or email [EMAIL PROTECTED] No phone calls please. We are an equal Opportunity Employer. -- Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems Lisa: Remember, Dad. The handle of the Big Dipper points to the North Star. Homer: That's nice, Lisa, but we're not in astronomy class. We're in the woods. The Call of the Simpsons
Job - London
Hi, We're looking for people interested in developing and running fantasy sports and videogame websites using mod_perl, HTML::Mason, MySQL, Linux. We developed this season's official UEFA Champions League game (http://www.uefagames.com), which had over 80,000 players, and have a lot of cool work in development for the Sydney 2000 Olympic Games and next seasons football (soccer) leagues. We're based by Regents Park, London. For more info check out http://www.ismltd.com/jobs.html or mail me. Ta, Mark.
Re: Want to work at a Game company?
I don't think an apology is in order. According to Jason's reply, you did the right thing! IMHO, it would be really nice if there were a separate list [or website] tailored for mod_perl job opportunities. I know that I would subscribe / visit. ;-) Have a GREAT day! "Graf, Chris" wrote: This was the default posting from HR. I should have thrown in the mod_perl requirement when sending to this list. All of our Perl is mod_perl, but HR didn't want to scare anyone away who might have been a good Perl programmer, but had never used mod_perl before (if it's possible to be good without using it). I know that most people on this list already have good jobs that they love, so maybe it isn't the best place to find someone. I am hoping to support any members of our community who feel like they could have more fun at work. I apologize for the spam. -Original Message- From: Jason Bodnar [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 18, 2000 12:00 PM To: Buddy Lee Haystack Cc: [EMAIL PROTECTED]; Graf, Chris Subject:Re: Want to work at a Game company? Yes it is. Doug has always encouraged mod_perl related jobs to be posted to this list. On 18-May-2000 Buddy Lee Haystack wrote: Is this the proper forum for this posting? "Graf, Chris" wrote: INTERNET DEVELOPER If you like the idea of working with unique, talented people and wearing jeans and a t-shirt to work, you're just the person we're looking for. Origin is a long-standing leader in the PC-gaming industry, and an acclaimed pioneer in the online gaming genre. We create Virtual Worlds that set the standard for interactive entertainment. We're currently searching for an Internet Developer to assist in the creation and maintenance of Internet applications and to support the creation of programming that will be compelling and interactive, enticing people to enter and explore our worlds with a focus on building and strengthening our relationships with the visitor/user-community. Additionally, to assist in high-level coding during HTML production/implementation and identify new advanced programming technologies for web site development. Qualified candidates should have: QUALIFICATIONS: · Proficient with Perl and SQL. · Experience with Internet tools. · Must be able to write and implement JavaScript and HTML. · Must understand SQL and demonstrate query writing ability. · Must possess an understanding of server administration. · Computer science degree or 2-3 years Internet programming experience desired. · The ability to multi-task in a fast paced environment, thrive in a team atmosphere and effectively work with all levels of mgmt. Located in the scenic hills of Northwest Austin, we offer a unique and casual work environment along with competitive salaries and a comprehensive benefits package. Origin offers challenging projects, excellent opportunities for advancement, and the freedom to be as creative as you can possibly be. At our facility, you will find an on-site fitness-center, café, free video games, pets and more. For immediate consideration, please send resume and salary requirements to: Origin Systems-Human Resources, 5918 W. Courtyard Drive, Austin, TX 78730 or fax to 512-346-7905 or email [EMAIL PROTECTED] No phone calls please. We are an equal Opportunity Employer. -- Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems Lisa: Remember, Dad. The handle of the Big Dipper points to the North Star. Homer: That's nice, Lisa, but we're not in astronomy class. We're in the woods. The Call of the Simpsons
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, brian moseley wrote:
On Thu, 18 May 2000, Autarch wrote:
C seems like serious overkill for something to simply
generate plain text output. How slow is making a string
in perl compared to doing it in C? I can't imagine
there's to much of a difference.
pretty slow if you build a string using .= instead of using
smarter methods, like pushing strings onto an array and then
joining it.
You tried to sell me that when I was at CP, and I didn't buy it then
either. This is a benchmark of .= versus join. 50 20-byte strings
are joined:
Concat: 2 wallclock secs ( 1.34 usr + 0.27 sys = 1.61 CPU)
Join: 4 wallclock secs ( 3.63 usr + 0.19 sys = 3.82 CPU)
.= concatenation is way faster. Also, building a 50-element array in
Perl takes up vastly more memory than building a 1000-byte string.
The string and the Perl process together require an RSS of 11MB, while the
array and the Perl process eat an RSS of 51MB.
Here is the benchmark program used:
my $iter = shift;
sub concat {
my $this;
for (my $i = 0; $i $iter; $i++) {
$this .= 'A'x20;
}
}
sub arrayjoin {
my @this;
for (my $i = 0; $i $iter; $i++) {
push(@this, 'A'x20);
}
join('', @this);
}
timethese(1, { 'Concat' = \concat, 'Join' = \arrayjoin });
The system was an Intel Pentium III 500 MHz with 128 MB of RAM and Linux
2.2.15. Swap was turned off.
-jwb
RE: Confusion on Apache::DBI
-Original Message- From: Niral Trivedi [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 18, 2000 1:11 PM To: '[EMAIL PROTECTED]' Subject: Confusion on Apache::DBI All, Sorry if this question sounds stupid.. but I am new to mod_perl and Apache::DBI.. I have successfully installed Apache Server 1.3.12 and mod_perl 1.24 and Apache::DBI 0.87 on Solaris 2.7. And I have tested all successfully... But confusion arised when I created a startup.pl file and tried to initiate DB connection in startup.pl file using 'connect_on_init' from Apache::DBI As I understood, if you have 'connect_on_init' in startup file, you have preloaded DB handle when first request comes in. And you don't need to open new db connection... But if I check the error_log file, I still have entry saying something like following: Apache::DBI caches by connect-string, so make sure that your DBI-connect call is identical to your Apache::DBI-connect_on_init call, including all the extra parameters. 10803 Apache::DBI need ping: yes 10803 Apache::DBI new connect to 'DatabaseNameUsernamePasswordAutoCommit=1PrintError=1' 10803 Apache::DBI disconnect (overloaded) And I will get this for first 4-5 request but after that each time I am getting are you sure that these 4-5 requests are for the same child? pay close attention to the pid... 10803 Apache::DBI need ping: yes 10803 Apache::DBI already connected to 'DatabaseNameUsernamePasswordAutoCommit=1PrintError=1' 10803 Apache::DBI disconnect (overloaded) Why is that??? Shouldn't I supposed to get 'already connected to' statement right from the first request yes, so long as you called connect_on_init properly. but don't forget, when a child is born, you'll get the 'new connect' output. connect doesn't happen at startup, per-se. that is, the parent process doesn't cache the handle, the child does... And how many open connection can I have at the same time?? As per my understood, for Apache::DBI connection pooling is based per server process. So, I guess as many server process you have, you can have db connection handle open at the same time.. AM I RIGHT HERE? yes, you will have as many database handles as you have httpd children... HTH --Geoff Please clear my doubts on this... And thanks for your help ... Niral
RE: Want to work at a Game company?
-Original Message- From: Buddy Lee Haystack [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 18, 2000 1:23 PM To: Graf, Chris Cc: [EMAIL PROTECTED] Subject: Re: Want to work at a Game company? I don't think an apology is in order. According to Jason's reply, you did the right thing! IMHO, it would be really nice if there were a separate list [or website] tailored for mod_perl job opportunities. I know that I would subscribe / visit. ;-) the mod_perl advocacy projects seems to come and go, so I'm not sure how recent this is... http://perl.apache.org/jobs.html --Geoff Have a GREAT day! "Graf, Chris" wrote: This was the default posting from HR. I should have thrown in the mod_perl requirement when sending to this list. All of our Perl is mod_perl, but HR didn't want to scare anyone away who might have been a good Perl programmer, but had never used mod_perl before (if it's possible to be good without using it). I know that most people on this list already have good jobs that they love, so maybe it isn't the best place to find someone. I am hoping to support any members of our community who feel like they could have more fun at work. I apologize for the spam. -Original Message- From: Jason Bodnar [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 18, 2000 12:00 PM To: Buddy Lee Haystack Cc: [EMAIL PROTECTED]; Graf, Chris Subject:Re: Want to work at a Game company? Yes it is. Doug has always encouraged mod_perl related jobs to be posted to this list. On 18-May-2000 Buddy Lee Haystack wrote: Is this the proper forum for this posting? "Graf, Chris" wrote: INTERNET DEVELOPER If you like the idea of working with unique, talented people and wearing jeans and a t-shirt to work, you're just the person we're looking for. Origin is a long-standing leader in the PC-gaming industry, and an acclaimed pioneer in the online gaming genre. We create Virtual Worlds that set the standard for interactive entertainment. We're currently searching for an Internet Developer to assist in the creation and maintenance of Internet applications and to support the creation of programming that will be compelling and interactive, enticing people to enter and explore our worlds with a focus on building and strengthening our relationships with the visitor/user-community. Additionally, to assist in high-level coding during HTML production/implementation and identify new advanced programming technologies for web site development. Qualified candidates should have: QUALIFICATIONS: · Proficient with Perl and SQL. · Experience with Internet tools. · Must be able to write and implement JavaScript and HTML. · Must understand SQL and demonstrate query writing ability. · Must possess an understanding of server administration. · Computer science degree or 2-3 years Internet programming experience desired. · The ability to multi-task in a fast paced environment, thrive in a team atmosphere and effectively work with all levels of mgmt. Located in the scenic hills of Northwest Austin, we offer a unique and casual work environment along with competitive salaries and a comprehensive benefits package. Origin offers challenging projects, excellent opportunities for advancement, and the freedom to be as creative as you can possibly be. At our facility, you will find an on-site fitness-center, café, free video games, pets and more. For immediate consideration, please send resume and salary requirements to: Origin Systems-Human Resources, 5918 W. Courtyard Drive, Austin, TX 78730 or fax to 512-346-7905 or email [EMAIL PROTECTED] No phone calls please. We are an equal Opportunity Employer. -- Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems Lisa: Remember, Dad. The handle of the Big Dipper points to the North Star. Homer: That's nice, Lisa, but we're not in astronomy class. We're in the woods. The Call of the Simpsons
Re: RFC: Apache::Request::Forms (or something similar)
Autarch wrote: I really don't think we need yet another module doing what CGI does. The people who've worked on the new version have done a very good job of addressing the memory and speed concerns people had about the current monolothic version. I think its much better to extend their work than to redo it. Based on the comment on CGI.pm v3, I guess a look-see at the new code is required. As you say, why re-implement the wheel? I'm primarily concerned with memory usage, and speed secondary. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Want to work at a Game company?
legitimate job offers from a reputable company are never spam. -- ___cliff [EMAIL PROTECTED] "Graf, Chris" wrote: This was the default posting from HR. I should have thrown in the mod_perl requirement when sending to this list. All of our Perl is mod_perl, but HR didn't want to scare anyone away who might have been a good Perl programmer, but had never used mod_perl before (if it's possible to be good without using it). I know that most people on this list already have good jobs that they love, so maybe it isn't the best place to find someone. I am hoping to support any members of our community who feel like they could have more fun at work. I apologize for the spam.
Win32 mod_perl 1.24 compile error.
hi,
Sitting here trying to get 1.24 to compile with VC6,
but keep getting stuck with the following linking error;
mod_perl.obj : error LNK2001: unresolved external symbol _ap_configtestonly
the symbol responsible for the error is in a condition at mod_perl.c line 738.
-- mod_perl.c ---
735:perl_tainting_set(s, cls-PerlTaintCheck);
736: (void)GvSV_init("Apache::__SendHeader");
737: (void)GvSV_init("Apache::__CurrentCallback");
738:if (ap_configtestonly)
739:GvSV_setiv(GvSV_init("Apache::Server::ConfigTestOnly"), TRUE);
740:
741:Apache__ServerReStarting(FALSE); /* just for -w */
742:Apache__ServerStarting_on();
--
however, if I comment out this condition ( 738 / 739) the compile passes with 0
warnings.
Looking at the version 1.22 of mod_perl.c, this condition was not present.
Libs:Perl 5.00503 / Apache 1.3.12
Am I missing something here, or can consider my build ok ?
thomas.
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Jeffrey W. Baker wrote: .= concatenation is way faster i don't have any results to back up my claim. therefore, my words are eaten :) i was convinced tho, even way back before you came to cp. i wonder what convinced me!
Apache::AuthDBI not setting $ENV{REMOTE_GROUP}
I've been using Apache::AuthDBI (and earlier, Apache::AuthenDBI) for a while, but never before have I used groups. I recently started trying to use groups, and with Apache::AuthDBI::DEBUG set to 2, I can get something like this in my error_log... 22310 Apache::AuthDBI::authz request type = initial main 22310 Apache::AuthDBI::authz user sent = robf 22310 Apache::AuthDBI::authz requirements: valid-user=1 user= group=admin 22310 Apache::AuthDBI::authz user_result = OK: valid-user 22310 Apache::AuthDBI::authz return OK As you can see, Apache::AuthDBI::authz is getting the group name 'admin' from the database, but the group name isn't passed in to my CGI script (I'm using Apache::Registry) at all. Any hints where the problem might be? Is it a bug in Apache::AuthDBI? Thanx, Rob -- Rob Fugina, Systems Guy [EMAIL PROTECTED] -- http://www.geekthing.com EA CF 09 1B AF 76 A9 D8 75 FE 26 6A E4 14 0A 3C Prenatal discretion is advised.
Re: Win32 mod_perl 1.24 compile error.
Sitting here trying to get 1.24 to compile with VC6,
but keep getting stuck with the following linking error;
mod_perl.obj : error LNK2001: unresolved external symbol
_ap_configtestonly
the symbol responsible for the error is in a condition at mod_perl.c line
738.
--
mod_perl.c ---
735:perl_tainting_set(s, cls-PerlTaintCheck);
736: (void)GvSV_init("Apache::__SendHeader");
737: (void)GvSV_init("Apache::__CurrentCallback");
738:if (ap_configtestonly)
739:GvSV_setiv(GvSV_init("Apache::Server::ConfigTestOnly"), TRUE);
740:
741:Apache__ServerReStarting(FALSE); /* just for -w */
742:Apache__ServerStarting_on();
---
---
however, if I comment out this condition ( 738 / 739) the compile passes
with 0 warnings.
Looking at the version 1.22 of mod_perl.c, this condition was not present.
Libs:Perl 5.00503 / Apache 1.3.12
Am I missing something here, or can consider my build ok ?
This snippet was added recently but apparently ap_configtestonly is not
exported in the Apache Windows DLL. Your build is ok, I'll fix this for
the next mod_perl version
--
Eric
missing ENV
We're upgrading from an NCSA only server to DigiCerts using Apache w/modperl modssl. We have *lots* of scripts in various languages expecting the company-specific ID code in REMOTE_USER, so I'm hacking it in with Perl*Handlers. Is there a way (such as with $c-user) to get the *browser* to report the right username on subsequent requests without a login dialogue? Paul TEMPVS PECVDEM COLLARE EST -- It's time to thin the herd. __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/
Re: Confusion on Apache::DBI
Thanks Geoff, You were right... I was using "DBI:mysql:DBNAME::localhost" as connect string in startup file whereas "DBI:mysql:DBNAME" in my mod_perl script.. I have changed that and it worked... Now, another question.. As we agreed, we can have as many db handle available as server processes are running.. Now, can we set number of db connection per server process in script or in startup script or any other way??? Because what I see is in this way... Let's say a child process can handle 10 request and then dies.. now it has one db connection available.. and it is processing one request which uses available db handle.. now what happen if another request comes in and ask for same db handle??? does that request has to wait for that or what??? If yes, then is there any way we can set number of connection per process?? I mean each child process can have 5 db connection open at the same time.. and it can grow upto 10.. So, if all 5 db handle are in use, and if 6th request comes in then process will open another connetion and it can do like this upto max of 10 connection.. Is it possible??? has anybody done this kind of things before Thanks again for your help.. Niral Geoffrey Young wrote:
RE: Confusion on Apache::DBI
-Original Message- From: Niral Trivedi [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 18, 2000 3:15 PM To: Geoffrey Young Cc: '[EMAIL PROTECTED]' Subject: Re: Confusion on Apache::DBI Thanks Geoff, You were right... I was using "DBI:mysql:DBNAME::localhost" as connect string in startup file whereas "DBI:mysql:DBNAME" in my mod_perl script.. I have changed that and it worked... Now, another question.. As we agreed, we can have as many db handle available as server processes are running.. Now, can we set number of db connection per server process in script or in startup script or any other way??? Because what I see is in this way... Let's say a child process can handle 10 request and then dies.. now it has one db connection available.. I believe that once the child dies, $dbh goes out of scope and DBI cleans up the connection. I could be wrong, though... and it is processing one request which uses available db handle.. now what happen if another request comes in and ask for same db handle??? well, another request won't come in and ask for the _same_ handle that died with the other child - that's the nature of Apache::DBI, one handle per child. It's not a pool of shared connections, really... Apache will either serve the new request to an existing child (which would get a cached connection) or initialize a new child (which would subsequently open a new connection and cache it)... does that request has to wait for that or what??? If yes, then is there any way we can set number of connection per process?? I mean each child process can have 5 db connection open at the same time.. and it can grow upto 10.. So, if all 5 db handle are in use, and if 6th request comes in then process will open another connetion and it can do like this upto max of 10 connection.. Is it possible??? has anybody done this kind of things before folks have talked about this type of stuff on the dbi-users list - it comes up every so often... I don't know that anyone has implemented a solution, though you might try looking at DBI::ProxyServer - I think it does something like this (though I haven't looked at it myself) --Geoff Thanks again for your help.. Niral Geoffrey Young wrote:
RE: Confusion on Apache::DBI
-Original Message- From: Niral Trivedi [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 18, 2000 3:57 PM To: Geoffrey Young Cc: '[EMAIL PROTECTED]' Subject: Re: Confusion on Apache::DBI Geoff, I know, once child dies, db handle goes out of scope and DBI cleans up the connection.. What I was asking is, we have directive called 'MaxRequestPerChild' for Apache server configuration which basically says how many request one child can process before it dies. So, if we have in 'httpd.conf' file 'MaxRequestPerChild 1000', that means, one child process will serv 1000 request and then it will die. Now, with Apache::DBI, we'll have one DBI handle per child process during the server startup. Now, let's say one child has started its processing and hasn't served any request yet. Now, first request comes in and it will look for DB handle, which is available and start processing it. Now, second request comes in for same child process and request for DBI handle, which is still serving first request. how would the child be available to serve another request but not have completed its DBI work? are you forking off a new process or something? So, what happened at this time to second request?? Does it have to wait for DBI handle to be free?? That's my question.. I think, second request has to wait.. i.e. it will be the same as normal CGI.. only difference is, we'll save overhead of opening a DB connection each time request comes in.. Correct me if I am wrong.. And I'll look in DBI::Proxy .. Thanks again for your help Geoff.. Niral Geoffrey Young wrote: -Original Message- From: Niral Trivedi [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 18, 2000 3:15 PM To: Geoffrey Young Cc: '[EMAIL PROTECTED]' Subject: Re: Confusion on Apache::DBI Thanks Geoff, You were right... I was using "DBI:mysql:DBNAME::localhost" as connect string in startup file whereas "DBI:mysql:DBNAME" in my mod_perl script.. I have changed that and it worked... Now, another question.. As we agreed, we can have as many db handle available as server processes are running.. Now, can we set number of db connection per server process in script or in startup script or any other way??? Because what I see is in this way... Let's say a child process can handle 10 request and then dies.. now it has one db connection available.. I believe that once the child dies, $dbh goes out of scope and DBI cleans up the connection. I could be wrong, though... and it is processing one request which uses available db handle.. now what happen if another request comes in and ask for same db handle??? well, another request won't come in and ask for the _same_ handle that died with the other child - that's the nature of Apache::DBI, one handle per child. It's not a pool of shared connections, really... Apache will either serve the new request to an existing child (which would get a cached connection) or initialize a new child (which would subsequently open a new connection and cache it)... does that request has to wait for that or what??? If yes, then is there any way we can set number of connection per process?? I mean each child process can have 5 db connection open at the same time.. and it can grow upto 10.. So, if all 5 db handle are in use, and if 6th request comes in then process will open another connetion and it can do like this upto max of 10 connection.. Is it possible??? has anybody done this kind of things before folks have talked about this type of stuff on the dbi-users list - it comes up every so often... I don't know that anyone has implemented a solution, though you might try looking at DBI::ProxyServer - I think it does something like this (though I haven't looked at it myself) --Geoff Thanks again for your help.. Niral Geoffrey Young wrote:
[preview] Search engine for the Guide
Ok, We have a preview ready for you. Randy Kobes worked hard to prepare this one. So your comments are very welcome. If you like it we'll put this into production. Please keep either the list CC'ed or if you reply to me in person, make sure you keep Randy CC'ed -- all the kudos should go his way :) So: The search is at: http://theoryx5.uwinnipeg.ca/cgi-bin/guide-search and the split guide is at: http://theoryx5.uwinnipeg.ca/guide/ Enjoy! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Want to work at a Game company?
On Thu, 18 May 2000, Buddy Lee Haystack wrote: I don't think an apology is in order. According to Jason's reply, you did the right thing! IMHO, it would be really nice if there were a separate list [or website] tailored for mod_perl job opportunities. I know that I would subscribe / visit. ;-) We have agreed on using subject [tags], so if you don't like to read specific tags, don't read it. I receive many job offers and I ask these people to resend these offers to the list, asking them to use the subject tag [JOB]. It worked quite well so far, just keep on educating people and you will be fine. But Chris chicken out and agreed that this was SPAM, while it was a ligitimate post with improper subject :) Have a GREAT day! "Graf, Chris" wrote: This was the default posting from HR. I should have thrown in the mod_perl requirement when sending to this list. All of our Perl is mod_perl, but HR didn't want to scare anyone away who might have been a good Perl programmer, but had never used mod_perl before (if it's possible to be good without using it). I know that most people on this list already have good jobs that they love, so maybe it isn't the best place to find someone. I am hoping to support any members of our community who feel like they could have more fun at work. I apologize for the spam. -Original Message- From: Jason Bodnar [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 18, 2000 12:00 PM To: Buddy Lee Haystack Cc: [EMAIL PROTECTED]; Graf, Chris Subject:Re: Want to work at a Game company? Yes it is. Doug has always encouraged mod_perl related jobs to be posted to this list. On 18-May-2000 Buddy Lee Haystack wrote: Is this the proper forum for this posting? "Graf, Chris" wrote: INTERNET DEVELOPER If you like the idea of working with unique, talented people and wearing jeans and a t-shirt to work, you're just the person we're looking for. Origin is a long-standing leader in the PC-gaming industry, and an acclaimed pioneer in the online gaming genre. We create Virtual Worlds that set the standard for interactive entertainment. We're currently searching for an Internet Developer to assist in the creation and maintenance of Internet applications and to support the creation of programming that will be compelling and interactive, enticing people to enter and explore our worlds with a focus on building and strengthening our relationships with the visitor/user-community. Additionally, to assist in high-level coding during HTML production/implementation and identify new advanced programming technologies for web site development. Qualified candidates should have: QUALIFICATIONS: · Proficient with Perl and SQL. · Experience with Internet tools. · Must be able to write and implement JavaScript and HTML. · Must understand SQL and demonstrate query writing ability. · Must possess an understanding of server administration. · Computer science degree or 2-3 years Internet programming experience desired. · The ability to multi-task in a fast paced environment, thrive in a team atmosphere and effectively work with all levels of mgmt. Located in the scenic hills of Northwest Austin, we offer a unique and casual work environment along with competitive salaries and a comprehensive benefits package. Origin offers challenging projects, excellent opportunities for advancement, and the freedom to be as creative as you can possibly be. At our facility, you will find an on-site fitness-center, café, free video games, pets and more. For immediate consideration, please send resume and salary requirements to: Origin Systems-Human Resources, 5918 W. Courtyard Drive, Austin, TX 78730 or fax to 512-346-7905 or email [EMAIL PROTECTED] No phone calls please. We are an equal Opportunity Employer. -- Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems Lisa: Remember, Dad. The handle of the Big Dipper points to the North Star. Homer: That's nice, Lisa, but we're not in astronomy class. We're in the woods. The Call of the Simpsons _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: [preview] Search engine for the Guide
On Fri, 19 May 2000, Stas Bekman wrote: Ok, We have a preview ready for you. Randy Kobes worked hard to prepare this one. So your comments are very welcome. If you like it we'll put this into production. Please keep either the list CC'ed or if you reply to me in person, make sure you keep Randy CC'ed -- all the kudos should go his way :) So: The search is at: http://theoryx5.uwinnipeg.ca/cgi-bin/guide-search and the split guide is at: http://theoryx5.uwinnipeg.ca/guide/ Looks cool, except can we take the guide splitting back 1 level? It seems to be split on =head2's, and should be split (IMO) on =head1's. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: [preview] Search engine for the Guide
On Fri, 19 May 2000, Stas Bekman wrote: Ok, We have a preview ready for you. Randy Kobes worked hard to prepare this one. So your comments are very welcome. If you like it we'll put this into production. Please keep either the list CC'ed or if you reply to me in person, make sure you keep Randy CC'ed -- all the kudos should go his way :) So: The search is at: http://theoryx5.uwinnipeg.ca/cgi-bin/guide-search and the split guide is at: http://theoryx5.uwinnipeg.ca/guide/ One more point... The indexer or the searcher (or both) has a broken tokenizer for anything involving perl. Try searching for Apache::Constants, for example. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Confusion on Apache::DBI
On Thu, 18 May 2000, Niral Trivedi wrote: Now, with Apache::DBI, we'll have one DBI handle per child process during the server startup. Now, let's say one child has started its processing and hasn't served any request yet. Now, first request comes in and it will look for DB handle, which is available and start processing it. Now, second request comes in for same child process and request for DBI handle, which is still serving first request. Niral, you're not understanding Apache's multi-process daemon approach. No child process will ever try to serve more than request at once. These are not multi-threaded processes. - Perrin
Re: [preview] Search engine for the Guide
On Thu, 18 May 2000, Matt Sergeant wrote:
Looks cool, except can we take the guide splitting back 1 level? It
seems to be split on =head2's, and should be split (IMO) on =head1's.
The reason for splitting on any =head level lies in fact that there are
huge sections under =head1 which have many =head{2,5}, and I'm slowly
reworking the Guide to making it more categorized (nested), rather than
flattened as it was before (and still is).
But we have thought about this issue. Look at the links at the bottom of
the splitted page -- it can take to the full version as well.
One more point... The indexer or the searcher (or both) has a broken
tokenizer for anything involving perl. Try searching for
Apache::Constants, for example.
That's right. It's broken :( After searching for 'Apache::Constants' I've
got 'apach constant'...
The :: are stripped on the fly, since these cannot be used in index, so
when you look for Foo::Bar you are actually looking for 'Foo Bar'.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Confusion on Apache::DBI
I understood now... Thank you all for your responses.. Niral Perrin Harkins wrote: On Thu, 18 May 2000, Niral Trivedi wrote: Now, with Apache::DBI, we'll have one DBI handle per child process during the server startup. Now, let's say one child has started its processing and hasn't served any request yet. Now, first request comes in and it will look for DB handle, which is available and start processing it. Now, second request comes in for same child process and request for DBI handle, which is still serving first request. Niral, you're not understanding Apache's multi-process daemon approach. No child process will ever try to serve more than request at once. These are not multi-threaded processes. - Perrin
Re: [preview] Search engine for the Guide
On Fri, 19 May 2000, Stas Bekman wrote: On Thu, 18 May 2000, Matt Sergeant wrote: One more point... The indexer or the searcher (or both) has a broken tokenizer for anything involving perl. Try searching for Apache::Constants, for example. That's right. It's broken :( After searching for 'Apache::Constants' I've got 'apach constant'... Just to expand on this - I turned stemming of words on by default in the search, which is why the stemmed words get returned. Perhaps it'll be better to turn stemming off by default, and rather make it a configureable option? The :: are stripped on the fly, since these cannot be used in index, so when you look for Foo::Bar you are actually looking for 'Foo Bar'. That's a limitation of swish-e - you can configure it to index characters like $, !, ... as part of a "word", but the characters , , *, and : cannot be so indexed. So the script silently stripped ':' out, leaving the search term to be 'Apache' 'Constants'. This should be mentioned on the search page Another thing that was configured in is that words have to be at least 3 characters long, which seems reasonable, and also there's some stopwords that don't get indexed, as they're too common. This list of stopwords is built by hand - so far it only includes 'perl' and 'modperl'. Also, the maximum number of hits is set at 30. best regards, randy
Re: [preview] Search engine for the Guide
Stas Bekman [EMAIL PROTECTED] wrote: Ok, We have a preview ready for you. Randy Kobes worked hard to prepare this one. So your comments are very welcome. If you like it we'll put this into production. Please keep either the list CC'ed or if you reply to me in person, make sure you keep Randy CC'ed -- all the kudos should go his way :) When I search for 'dbi' or 'DBI', it finds nothing, and the search box shows 'dby'! It looks like it's try to helpfully change my search pattern... -- Jeremy Howard [EMAIL PROTECTED]
Re: missing ENV
At 09:14 AM 5/18/00 -0700, Paul wrote: We're upgrading from an NCSA only server to DigiCerts using Apache w/modperl modssl. We have *lots* of scripts in various languages expecting the company-specific ID code in REMOTE_USER, so I'm hacking it in with Perl*Handlers. Is there a way (such as with $c-user) to get the *browser* to report the right username on subsequent requests without a login dialogue? No. You need to pass remote user to the browser using a form var then. I assume you are making use of JavaScript or Java or some other client side stuff. Your message is a little confusing to me as to what you are accomplishing since you open up with a server-side scenario and then close with a question about client-side behavior being affected by possibly setting $c-user? Anyway, if your concern turns out to be server side, writing a handler to set REMOTE_USER should be fairly simple since mod_ssl is extremely flexible with the information it exports to the environment from the digital cert. All you need is an appropriate set of mapping rules. BTW, just because you use digital certs does not necessarily preclude you from a basic auth system either for these old scripts. Digital certs are transferred on the SSL stream, Basic Auth credentials are transferred after the SSL Stream is authenticated. Although it seems a pain. Anyway, since I didn't quite understand where your issue comes from, I included more information than you probably wanted. Sorry about that in advance. Good Luck, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: RFC: Apache::Request::Forms (or something similar)
At 10:53 AM 5/18/00 -0700, brian moseley wrote: On Thu, 18 May 2000, Jeffrey W. Baker wrote: .= concatenation is way faster i don't have any results to back up my claim. therefore, my words are eaten :) i was convinced tho, even way back before you came to cp. i wonder what convinced me! You never know. Perl comes up with smarter and smarter optimizations all the time. Perhaps if the same benchmark were run on Perl 5.003 you would get a different result. eg I think there was a thread on this list way back about OO method calls versus direct package references... and people said that OO method calls have a lot of overhead, but I think in later versions of Perl, OO method call paths are cached(?) and so method calls no longer have the same overhead as they used to. Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: [preview] Search engine for the Guide
On Thu, 18 May 2000, Jeremy Howard wrote: Stas Bekman [EMAIL PROTECTED] wrote: Ok, We have a preview ready for you. Randy Kobes worked hard to prepare this one. So your comments are very welcome. If you like it we'll put this into production. Please keep either the list CC'ed or if you reply to me in person, make sure you keep Randy CC'ed -- all the kudos should go his way :) When I search for 'dbi' or 'DBI', it finds nothing, and the search box shows 'dby'! It looks like it's try to helpfully change my search pattern... Hi, I turned stemming on by default - that's why the search pattern gets changed. This obviously causes confusion - I'll turn it off, and make it manually configurable. As well, the indexing was configured for words greater than 3 characters; I'll reduce it down to greater than 2 characters and see if that helps. best regards, randy
Prb: Apache::DB plus Perl 5.6 doesn't break
Well, that subject line looks a bit odd, doesn't it? What I mean is that with Perl 5.6.0, Apache::DB is broken, because it doesn't break... Er, that is, you can add breakpoints, but Apache::DB never actually breaks on them. Is anyone else having this problem? Is there a new version in the works? -- Jeremy Howard [EMAIL PROTECTED]
Re: 100% sessions?
At 19:26 09/05/00 -0700, Tom Mornini wrote: On Tue, 9 May 2000, Tobias Hoellrich wrote: and what happens when somebody bookmarks a URL with the session-id prepended and comes back a week later with an invalid session-id in the URL? They get a screen that asks them to fix their bookmark, and shows them how. This is the only disadvantage of this method that we know of, but we feel that it is far outweighed by having session support on 100% of our connections. -- -- Tom Mornini -- InfoMania Printing and Prepress Or you could just create a frame with "0,*" and the location bar would always show your domain name, and that's what they'd bookmark regards, Gustavo Henrique Maultasch [EMAIL PROTECTED]
Re: Prb: Apache::DB plus Perl 5.6 doesn't break
Well, that subject line looks a bit odd, doesn't it? What I mean is that with Perl 5.6.0, Apache::DB is broken, because it doesn't break... Er, that is, you can add breakpoints, but Apache::DB never actually breaks on them. Is anyone else having this problem? Is there a new version in the works? I've got a bit more info on this now. Nothing has changed on my PC (Linux RH 6.2) since this morning, other than updating Perl from 5.005_03 to 5.6.0. Apache::DB _was_ working fine. When I add a breakpoint, tab completion works fine to enter a sub name, and no errors are given by the debugger. However, doing an 'L' doesn't show any breakpoints, and no breaks occur. I've tried replacing perl5db.pl in 5.6.0 with the version from 5.005_03, but the behaviour is the same. Anyone else having this trouble? Anyone successfully used Apache::DB in 5.6.0? -- Jeremy Howard [EMAIL PROTECTED]
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Drew Taylor wrote:
I personally have code that puts a CGI.pm object in the
object ($self), which is then used for both HTML
generation AND fetching params AND cookies.
For example, I have lines like 'my $val =
$self-{CGI}-param('blah')' as well as 'my $form =
$self-{CGI}-popup_menu(-name='blah', ...)'. The
effect is to emulate CGI.pm, while being leaner
simpler.
am i missing something..? you're actually /using/ CGI.pm
inside your new module?
