Re: mod_perl advocacy project resurrection
Chris Winters writes: Along with the open-source Servlet/JSP/Web Engine servers (among others): Apache Tomcat: http://jakarta.apache.org/ Jetty: http://jetty.mortbay.com/ I'm currently using the Tomcat at work, and I have to say that although I really love perl and mod_perl, there are real advantages to using java. Over the past couple of years that I've been mostly lurking on this list there have been a couple common threads: 1) Memory Usage: embedding the perl interpreter on every process uses lots of memory. This of course can be tweaked and isn't as bad on good OS's, but it is a common thread. 2) Sharing information between the processes. There's lots of different ways to do it, but none really jumps out as an end-all solution. With a system like Tomcat running in a jvm outside of apache, you only have one jvm, and you get things like being able to share a cache between all sessions alot easier. I personally find the configuration of mod_perl to be more straight forward than Tomcat, but I do see some advantages to that system (I'm sure there are some speed disadvantages to the tomcat communcation, but haven't done any benchmarks). That being said, I wonder how difficult it would be pull the perl intepreter out of mod_perl and run a perl stand-alone multi-threaded daemon which listens for mod_perl api calls... :) Things I would never even try with java: 1) Talking any client/server protocol other than URLs. The perl mail/ftp modules are so easy to use and they work great. I don't even want to think about writing to syslogd from inside java... :) 2) Spawning an external process. I try not do it in mod_perl, but I have never been able to pull it off in java. -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Jim Woodgate wrote: With a system like Tomcat running in a jvm outside of apache, you only have one jvm, and you get things like being able to share a cache between all sessions alot easier. [snip] That being said, I wonder how difficult it would be pull the perl intepreter out of mod_perl and run a perl stand-alone multi-threaded daemon which listens for mod_perl api calls... :) There is Velocigen and SpeedyCGI (or is it FastCGI?). These basically create a pool of perl interpreter daemons that respond to requests. The problem with them compared to mod_perl is that you don't have access to the server internals so you can really only affect the content handling phase. Is this the case with Tomcat as well? If so, I'd say its not really comparable to mod_perl. -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
At 02:18 AM 12/6/2000 -0600, Dave Rolsky wrote: On Wed, 6 Dec 2000, Jim Woodgate wrote: With a system like Tomcat running in a jvm outside of apache, you only have one jvm, and you get things like being able to share a cache between all sessions alot easier. [snip] That being said, I wonder how difficult it would be pull the perl intepreter out of mod_perl and run a perl stand-alone multi-threaded daemon which listens for mod_perl api calls... :) There is Velocigen and SpeedyCGI (or is it FastCGI?). These basically create a pool of perl interpreter daemons that respond to requests. The problem with them compared to mod_perl is that you don't have access to the server internals so you can really only affect the content handling phase. Is this the case with Tomcat as well? Yes this is the case with tomcat. If so, I'd say its not really comparable to mod_perl. It is very comparable. In the advocacy of mod_perl we are talking about losing MAJOR ground to PHP and Java from a web applications development perspective. So I think it is comparable. The fact that mod_perl can modify the internals of apache is an icing on the cake to most real-world programmers and won't make them use mod_perl or Perl at all until it becomes as easy as PHP. SpeedyCGI and TomCat are really very easy to get up and running and coding away compared to mod_perl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, (Matthew Kennedy) wrote: Transaction support for your business logic is easy in J2EE. It's not clear how you do this in Perl? Use an RDBMS. You don't understand that it can have nothing to do with a RDBMS. I'm not talking about transaction control within the context of a database within a RDBMS. As I wrote to another user on this list, say you have two database servers and you need to implement a process which operates on each database in order. Maybe you move an item from on to the other. What if the second operation fails? Natually you want to roll-back to before the operation on the first. That's what J2EE transactions are about. See how RDMBS transactions are a different deal in this situation? The problem with this analogy is that in Perl we'd just use exception handling with automatic rollback on the databases in question (assuming you don't commit). Throw an exception and be done with it. You'd probably have to come up with a better scenario where J2EE transaction management is really required. I've been struggling to grasp the need for this concept since I attended a Microsoft developer day where they demo'd their COM based transaction manager for the first time. But then I'm an old style RDBMS guy. We built multi-million dollar Sybase systems for large insurance companies. We never needed a transaction manger. shrug; -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: I haven't looked at AO or AxKit, but if I can untar either one of them and just get to work, that will rule. You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: On Tue, 5 Dec 2000, brian moseley wrote: On Tue, 5 Dec 2000, Perrin Harkins wrote: Transaction support for your business logic is easy in J2EE. It's not clear how you do this in Perl? Use an RDBMS. what about transactions that span data sources? yes, this does happen. Yeah, it *seems* to happen, but it doesn't actually. Any vendor who tells you he can do real transactions across data sources is a liar, or using a new and improved definition of transaction. You can do it %99.99 of the time but that last %.01 is the bitch. With J2EE you get the complete illusion that you are doing txns across as many data sources on as many systems and vendors as you want, but behind the illusion there is the nonzero risk that the data is inconsistent. In a real transactional system, you can never have inconsistent data. This thread is suffering from a severe lack of technical information. Can you go into more technical detail on what that 0.01% is (and is caused by)? -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Debugging Apache::ASP
Hi, We've been using Apache::ASP over the past one month. We are having problems debugging an ASP program. We have set the debug level to 3 but still. At debug level 3, the line in which the error occurs is displayed. But if we have multiple statements withing % and % tags then, the error display only gives only one line number (line number of the first statement) is displayed. We are finding it very difficult to identify the exact line where the error has occured. In general we find Apache::ASP support for debugging quite poor. Are there any tools which we are missing out ?? How do others tackle this ?? How do people track "use of uninitialised variable". Thanks, S Muthu Ganesh Differentiated Software Solutions Pvt. Ltd., 176, Ground Floor, 6th Main, 2nd Block, RT Nagar, Bangalore - 560032 Visit us at www.diffsoft.com
Re: enterprise mod_perl architectures
"Gerald Richter" [EMAIL PROTECTED] writes: 3) Is there anyone who'd like to volunteer virtual space to host this? e.g. ftp, web, creating a mailing list, etc. I can do this, but I guess it also wouldn't be a problem to host this on perl.apache.org This is, IMHO, a mod_perl advocacy effort and should sit on that site quite nicely... -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, brian moseley wrote: [coldfusion/php] how is mason not like this? It has no point-n-drool authoring tools. This is actually the killer app. Once this is done, Mason / other templating system of choice gets catapulted to the forefront MBM -- Matthew Byng-Maddick Home: [EMAIL PROTECTED] +44 20 8981 8633 (Home) http://colondot.net/ Work: [EMAIL PROTECTED] +44 7956 613942 (Mobile) Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: crash on connect (DBI/mysql) (2)
Bas,
thanks for your comments. They are a first step to solve the problem.
[DBI script problem skipped]
The error_log from Apache shows some problems, which
*could* be related to
mod_perl
[Tue Dec 5 09:42:31 2000] [crit] (13)Permission denied:
make_sock: could
not bi
nd to port 80
Uhm, before we try to solve the problem in hand, I don't
understand your
statement of Apache showing *some* problems. What port are you running
mod_perl server at? 80? do you run a single mod_perl server
or is there a
front-end server?
I run apache/mod_perl as a single httpd server at port 80.
It might be a uid/gid problem. I replaced httpd/httpd (which were just
copied from a different Apache installation) by nobody/nobody.
The server restarts clean now:
[Tue Dec 5 16:05:12 2000] [notice] FastCGI: process manager initialized
(pid 28
76)
[Tue Dec 5 16:05:12 2000] [notice] Apache/1.3.12 (Unix) mod_fastcgi/2.2.8
PHP/4
.0.2 mod_perl/1.24 configured -- resuming normal operations
As you notice, Apache also runs a fastgci module, which I eventually want to
replace by mod_perl applications.
Second, you should make your code more debug friendly. Replace:
$dbh = DBI-connect('dbi:mysql:vip;host=', '###', '###');
with
$dbh = DBI-connect('dbi:mysql:vip;host=', '###', '###')
or die $DBI::errstr;
what error do you get?
I modified my code, the error_log shows a seg fault for each call to the
mod_perl script:
[Tue Dec 5 16:05:38 2000] [notice] child pid 2878 exit signal Segmentation
Faul
t (11)
[Tue Dec 5 16:05:40 2000] [notice] child pid 2877 exit signal Segmentation
Faul
t (11)
[Tue Dec 5 16:05:41 2000] [notice] child pid 2879 exit signal Segmentation
Faul
t (11)
[Tue Dec 5 16:05:42 2000] [notice] child pid 2880 exit signal Segmentation
Faul
t (11)
[Tue Dec 5 16:06:42 2000] [notice] child pid 2884 exit signal Segmentation
Faul
t (11)
At least the error_log shows now that mod_perl crashes before being able to
echo the
diagnostic DBI::errstr .
Wessel Kraaij, TNO-TPD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Debugging Apache::ASP
Hi there, On Wed, 6 Dec 2000, Differentiated Software Solutions Pvt. Ltd., wrote: We are having problems debugging an ASP program. [snip] How do others tackle this ?? % do_something(); % % print STDERR $omething; % % do_something_else(); % % print STDERR $omething_else; % How do people track "use of uninitialised variable". I initialise all my variables. 73, Ged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache::ASP problem with post data
hello ,
i'm working on a project that involves some XML-RPC system. The idea is
to POST a XML to a ASP script which will than process this
and return a XML back to the client.
To do that a send sommething like this (output from ethereal dump) :
POST /cp-bin/rc2.asp HTTP/1.0
Host: linux
User-Agent: libwww-perl/5.36
Content-Length: 156
Content-Type: text/xml
?xml version="1.0"?
methodCall
methodNameexamples.getStateName/methodName
params
paramvaluei41/i4/value/param
/params
/methodCall
The problem now is , that in the asp script i get a Totalbytes of 156
bytes but the content string is empty ?
#Get posted XML query
my $len = $Request-{TotalBytes};
my $i = $Request-BinaryRead($len);
#log input query
$Response-Debug("recieved $len bytes");
$Response-Debug("data [$i]");
Does anybody has a clue where the 156 bytes are ???
thanks
luc willems
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On Tue, 5 Dec 2000, kyle dawkins wrote: [1. two types of developer] agreed. [2. Perl4 / Perl5 ] This is also true. Although a lot of "Perl programmers" haven't got a clue about the object orientation stuff in Perl5 either. On the other side of the coin, too many people are jumping on the "It's object oriented, it must be reusable" and "The only way to solve problems is using objects" bandwagons. Java and C++ both play to these. And unfortunately they've convinced management, in general. Plus, big corporates like to deal with corporates - Java is defined by Sun, a corporate. This is always going to make our life hard... 3. Installation/setup Ok, so if you have Linux, it's a piece of cake... download all the sources, OK. but s/Linux/a UNIX or UNIX-alike/g. follow the README's, and go. But what if you don't have Linux? Or you aren't root, and what if you need access to httpd.conf to keep changing Then you don't necessarily do it on port 80. This is the only reason you need to be root. stuff? And developers are going to need to cycle the server all the time, so they need the ability to do that, too... it's definitely a weak point. I can install any one of the Java-based web application frameworks and be developing immediately. I disagree. The webserver stuff still needs to be run as root, or you run it on a different port. Although I would also suggest having a look at userv (http://www.chiark.greenend.org.uk/~ian/userv/), although there are some security holes opened up by using mod_perl. 4. Isolation A lot of mod_perl projects (or even Perl projects in general) tend to be one-person shows... maybe I'm wrong, and I'd love it if people could correct me! But in my observation, we have a lot of programmers working in isolation. This is bad. plughttp://codix.net//plug. 5. Foundation libraries Because of the open nature of the CPAN community, there are a lot of great modules floating around out there. However, there is no real API consistency in them, and this will cause newcomers to Perl a fair amount of trouble. Moreover, we're not going to get anywhere in the enterprise if people insist on using HTML templating systems that allow the embedding of code within HTML. It's straight up and down a total disaster and no right-minded software architect would ever consider it. Agreed. 6. Engineering The Perl community is made up of a truly eclectic group of people, which is an amazing strength. However, it's also an amazing weakness: I get the impression that very few programmers in the Perl community spend a lot of time *reading* books on software engineering and techniques thereof... and I'm not convinced about this. Although from my limited experience, I'm not very fond of them that lack of knowledge tends to bleed over into a lot of code out there. We have a HUGE problem in the community of the "coder superstar" mentality... yup. which is very dangerous. Perl allows far too many tricks, and often code ends up totally unmaintainable and unreadable because some coding yahoo put in some glory-code. It happens in many languages, true, but Perl is the ideal environment for it. Not necessarily. You can get coder superstars who write maintainable and understandable code. -- SO -- I hope you guys can give these points some thought. I could be "smoking grass" but I think I'm on target on most of my points and I'd love to hear what you guys think too. In the meantime, here are some ideas that might go down well (or not!): Not entirely. * We implement a "mode" under mod_perl, kind of like "use strict", that suddenly forces Perl to behave well from an object-oriented standpoint. By this, I mean taking some of the power away from Perl that causes trouble, like allowing anyone to write instance data on an arbitrary instance of a class... No. no no no. Forcing perl to behave as "Object oriented" is entirely the wrong thing. This is why Java sucks so much. "Everything is an object" (excepting, obviously, the language primitives). Perl is nice because you can write it functionally or object oriented depending on the problem you're trying to solve. Also this functionality is more core Perl than mod_perl. * We "homogenise" some foundation classes. This means we create a *suite* of classes that have consistent API, are designed together as a framework, and are easy to learn I think you need to get out of the "object-oriented-only" mentality. But yes, sort of, agreed. * We need to drop-kick DBI out of the park... it's not that it's bad (it's actually great... kudos to the DBI crew) but kind of the opposite; it's so easy to use that most people don't think beyond it. How many of you have ever thought about implementing an Object-Relational middleware layer using mod_perl? We could create a set of generic OR classes as part of our foundation framework. DBI is actually quite a hassle to use
RE: crash on connect (DBI/mysql) (2)
The server restarts clean now:
good
Second, you should make your code more debug friendly. Replace:
$dbh = DBI-connect('dbi:mysql:vip;host=', '###', '###');
with
$dbh = DBI-connect('dbi:mysql:vip;host=', '###', '###')
or die $DBI::errstr;
what error do you get?
I modified my code, the error_log shows a seg fault for each call to the
mod_perl script:
[Tue Dec 5 16:05:38 2000] [notice] child pid 2878 exit signal Segmentation
Faul
t (11)
[Tue Dec 5 16:05:40 2000] [notice] child pid 2877 exit signal Segmentation
Faul
t (11)
[Tue Dec 5 16:05:41 2000] [notice] child pid 2879 exit signal Segmentation
Faul
t (11)
[Tue Dec 5 16:05:42 2000] [notice] child pid 2880 exit signal Segmentation
Faul
t (11)
[Tue Dec 5 16:06:42 2000] [notice] child pid 2884 exit signal Segmentation
Faul
t (11)
At least the error_log shows now that mod_perl crashes before being able to
echo the
diagnostic DBI::errstr .
Good, so now you read the SUPPORT file and follow the instructions on how
to provide the segfault trace.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Debugging Apache::ASP
On Wed, 6 Dec 2000, Differentiated Software Solutions Pvt. Ltd., wrote:
Hi,
We've been using Apache::ASP over the past one month.
We are having problems debugging an ASP program.
We have set the debug level to 3 but still.
At debug level 3, the line in which the error occurs is displayed.
But if we have multiple statements withing % and % tags then, the error display
only gives only one line number (line number of the first statement) is displayed. We
are finding it very difficult to identify the exact line where the error has occured.
In general we find Apache::ASP support for debugging quite poor. Are there any tools
which we are missing out ??
How do others tackle this ??
How do people track "use of uninitialised variable".
use Carp ();
$SIG{__WARN__} = \Carp::cluck;
Thanks,
S Muthu Ganesh
Differentiated Software Solutions Pvt. Ltd.,
176, Ground Floor, 6th Main,
2nd Block, RT Nagar,
Bangalore - 560032
Visit us at www.diffsoft.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://jazzvalley.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: enterprise mod_perl architectures
On 6 Dec 2000, David Hodgkinson wrote: "Gerald Richter" [EMAIL PROTECTED] writes: 3) Is there anyone who'd like to volunteer virtual space to host this? e.g. ftp, web, creating a mailing list, etc. I can do this, but I guess it also wouldn't be a problem to host this on perl.apache.org This is, IMHO, a mod_perl advocacy effort and should sit on that site quite nicely... We even have a special list for that, which wasn't really used because people didn't signup. So we can do it now. (well I'm there :) http://perl.apache.org/#advocacy-list -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
J2EE and distributed commits (was Re: mod_perl advocacy project resurrection)
I'll bite, 'cuz I think I've run several times recently into this sort of issue. I've not done anything with J2EE, so there's a risk that I've misunderstood _that_. Now, from the top: On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: With J2EE you get the complete illusion that you are doing txns across as many data sources on as many systems and vendors as you want, but behind the illusion there is the nonzero risk that the data is inconsistent. In a real transactional system, you can never have inconsistent data. Logged relational databases have evolved to ensure "atomic"[1] transactions. This is to avoid embarrassing incidents like me giving you a dollar[2], but a system crash midway means that we both end up with the dollar. Or neither of us have it. If the application catches a SIGKILL (say), the RDBMS "rolls back" to the beginning of the transaction (I've still got my dollar). If the RDBMS catches a SIGKILL, or a digger goes through the power cable, the system is built so that it can restore itself to its previous state. A variety of safeguards are used so that transactions are very hard to lose. Often, a TX is not regarded as committed until it's been written to disk. Logs are periodically written to tape, in case the disk gets scrunched (or the RDBMS software blows up). In short: The losing of transactions is Greatly Discouraged, but can happen. _Inconsistant_ processing of transactions should be *impossible*. Distributed transactions, where you have two systems (say my bank and yours are on separate machines), simply cannot be made as reliable. There is *always* the problem that, in a single system, there is _A_ log that records whether the transaction has happened. With two systems, the record must be made in two places, and there is always an instant in time - however small - when one system can crash leaving the other believing that the transaction has been successful. (IIRC, textbooks sometimes call this the "red white army problem"). This sort of problem is *not* confined to finance. You may, for instance, be maintaining lists of usernames passwords in multiple locations. There are a variety of approaches to this sort of problem: 1. Use a single database. 2. Make one database the "slave" of the other. If the DB is too big to copy, you can use a "hybrid" approach where changes are propagated, but the DBs are periodically sync'd. Or use something like rsync, which makes two database/file trees /whatever identical without brute-force copying the whole thing. 3. Be careful with foreign keys on other people's servers ... since there may be no way to find out when those become invalid, or point to something else. (Hence, the dreaded "link rot" suffered by search engines). As evidenced by the WWW's popularity explosion, loosely coupled distributed systems are in many ways very powerful. Trying to force "everything" via a single system, whilst tackling problems of consistency transaction processing, can be crippling. Different approaches suit different apps, but pretending the problem isn't there isn't generally a good approach. Hope that helps. -- Tim Sweetman A L Digital 'Now you see this one-eyed midget shouting the word "now"...' --- Bob Dylan [1] That's unsplittable, like atoms are, except the radioactive ones, or if you're cheating and have a particle accelerator. [2] I'm guessing there are lots of Americans here, and going with the majority. When Euros are in wider use, I'll use that as my metasyntactic currency unit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
Stas Bekman wrote: Well as you've probably figured out, based on the load of email from me, I've dropped my last job, in order to finally finish the mod_perl book, have some rest and make a push to mod_perl. Well best of luck hope you have a good rest - I'll certainly buy the book! In Paris we couldn't hire a single mod_perl programmer, because people don't even know what that. They know a lot about php and ASP. It's true that they don't even know what's Perl :( I think this is a general situation - sounds similar to the uk. But, you all know that php pretty much takes over. Why? For two reasons: 1) initial corporate pushing (press/ads) 2) once well known, the word of the mouth does the rest. Well go back 2 / 2 1/2 years and PHP was little known. mod_perl lucks the corporate money/PR to get pushed. But we can still work on the exposure, which will bring corporate money/PR thru the word of the mouth. I think your on the right track, as many other popular open source things have started this way. \ Luckily Matt has got sick of waiting for someone to work on the advocacy of mod_perl and he has just taken over it. Having a good informational site is good, but it's not enough. We need to solve the problem of people to find this site and wanting to use mod_perl. Solution? Spreading the word. I see two main streams: 1) Online zines. 2) Conferences. I think that we should start working on locating ezines wanting to publish mod_perl related articles (preferrably for a fee, to give incentives for others to write) and conferences where mod_perl can be relevant. The data is to be collected and distributed to the people who wish to advocate mod_perl, thru written articles and conference classes. I suppose that we will also look for companies who want to order mod_perl classes and find the teachers in the appropriate areas. I think may people could write simple "How to ZXY" in mod_perl. PHP has excellent resources for similar things i.e how to do this or that. Very much like the Perl Cookbook. I am not saying that mod_perl does not have these, and the guide has some excellent examples, but these are often not easy to find and will not attact people half as much as reading a single all-in one atricle. May be we could organize some certification classes, to give more PR to mod_perl. Not wishing to sound negative - but certification more often causes problems - MCSE's a case in point. Overall Stas I think more aticles in the general IT press be it ezines or in paper is the way to go to raise the profile. As an aside whats happening to perl month ? as this appears to be exactly the sort of thing we need. Greg I suppose that much more can be done. Comments are welcome. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Matt Sergeant [EMAIL PROTECTED] writes: On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: I haven't looked at AO or AxKit, but if I can untar either one of them and just get to work, that will rule. You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. Isn't that just a question of getting a Bundle::AxKit together? Or is that an egg-sucking thing... -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On 6 Dec 2000, David Hodgkinson wrote: Matt Sergeant [EMAIL PROTECTED] writes: On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: I haven't looked at AO or AxKit, but if I can untar either one of them and just get to work, that will rule. You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. Isn't that just a question of getting a Bundle::AxKit together? Or is that an egg-sucking thing... Bundles are for when you don't have a dependency tree, which AxKit has. But the real problem is the non-perl modules. And the fact that AxKit doesn't seem to work with PHP. And the Apache-expat bug/problem. All these things make installing AxKit a bit non-trivial. I quite like the Zope model - a single distribution which just includes and installs everything you need in a single place. You get python, the httpd, the database, everything. Of course if you have more complex needs, like running Zope from within Apache, you need to do some extra work, but out of the boz Zope gives you a great system that just runs. We could do that with AxKit - just ship it with Apache, mod_perl, the whole lot. But I don't think that would appeal to Perl people somehow. Thoughts? -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Matthew Byng-Maddick wrote: On Tue, 5 Dec 2000, kyle dawkins wrote: * We implement a "mode" under mod_perl, kind of like "use strict", that suddenly forces Perl to behave well from an object-oriented standpoint. By this, I mean taking some of the power away from Perl that causes trouble, like allowing anyone to write instance data on an arbitrary instance of a class... People are looking at this sort of thing. Damian Conway wrote Tie::SecureHash and Class::Contract, which may be driving at this sort of thing. The latter implements "design by contract", as seen in Eiffel. I read Damien's paper on it, but haven't used it - there are four things that put me off: 1. The difficulty of modifying existing classes to work with it 2. The magic of "flyweight scalars", which I haven't yet got my head around 3. "This code is funky"-type disclaimers scare me. 4. It looks like he just defines "data types" as LIST, ARRAY, the usual Perl primitives. This is of limited use, IMHO; being able to _define_ rules for data types (eg. valid URI; reference to FooID in table Foo in database bar) would be more powerful. (Not that these should all be checked every time, unless you're implementing a Snail, but C::C does have the ability to switch checks off, eg, in a live environment. Though live users make very thorough testers :-/) I can see why people want encapsulation, though I've rarely seen problems due to people violating it. This may be pure luck. *Lack* of encapsulation may provide clues when you hit something with Data::Dumper find out what's going on on the inside. IMHO, assertions, data type definitions, pre post conditions are v. useful things. Define interfaces to methods functions. This isn't necessarily the right approach - especially at the beginning of a project - but it is in some cases, and AFAIK there is little to automate this stuff available in Perl. Putting up these walls can *really* help isolate problems. Eiffel Class::Contract allow conditions to be *inherited*. So these approaches work hand-in-hand with OO *and/or* re-use. Cheers -- Tim Sweetman A L Digital 'Now you see this one-eyed midget shouting the word "now"...' --- Bob Dylan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
I've dropped my last job, in order to finally finish the mod_perl book, have some rest and make a push to mod_perl. Well best of luck hope you have a good rest - I'll certainly buy the book! :) I see two main streams: 1) Online zines. 2) Conferences. I think that we should start working on locating ezines wanting to publish mod_perl related articles (preferrably for a fee, to give incentives for others to write) and conferences where mod_perl can be relevant. The data is to be collected and distributed to the people who wish to advocate mod_perl, thru written articles and conference classes. I suppose that we will also look for companies who want to order mod_perl classes and find the teachers in the appropriate areas. I think may people could write simple "How to ZXY" in mod_perl. PHP has excellent resources for similar things i.e how to do this or that. Very much like the Perl Cookbook. I am not saying that mod_perl does not have these, and the guide has some excellent examples, but these are often not easy to find and will not attact people half as much as reading a single all-in one atricle. Right, so anybody wants to get famous (well at least a little :), you wrote some cool code snippet -- describe the gist, attach the source and let others look over it. Sort of WebTechniques columns by Randal. May be we could organize some certification classes, to give more PR to mod_perl. Not wishing to sound negative - but certification more often causes problems - MCSE's a case in point. well, may be. Obviously we don't need certifications when we cannot find mod_perl programmers at all. I just thought about it as the counter-intuitive solution -- create the certification program and make people think that there are so many mod_perl programmers that we there was a need for a certification -- which will bring to the interest, since people believe that if someone is running certification program it must be good. And then once started to learn Perl/mod_perl he is actually going to realize that it's good indeed. Overall Stas I think more aticles in the general IT press be it ezines or in paper is the way to go to raise the profile. Yeah, but I don't seem to make other interested. I don't know why. Folks are too busy I guess. As an aside whats happening to perl month ? as this appears to be exactly the sort of thing we need. I don't know. Baiju told me back in August that he resumes the functionality but he has dissapeared since then. I'll try to reach him. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, Dec 06, 2000 at 12:08:59PM +, Matt Sergeant wrote: We could do that with AxKit - just ship it with Apache, mod_perl, the whole lot. But I don't think that would appeal to Perl people somehow. Thoughts? We're not (really) talking about appealing to "Perl people" here, I think, but about appealing to people who know how to spell "Perl". By this I mean we are talking about attracting developers who haven't climbed the learning curves for Perl and Apache and mod_perl and DBI and so on and would like an easy way to play with these things. If you could do a few stand-alone releases you're proposing without having to maintain too many binary releases, you would probably woo more people in to trying it. There's a big something to be said for being able to grab a "starter kit" that "just works" and play with it. Do that for RH6 7 and NT and promote the kits as nice, shallow jumping-in places and more folks will get in and paddle around a bit with AxKit, I think. If you could release a source distro of same with a big, red "make" button on it that would allow folks on FreeBSD, debian, wherever to take a stab at it too, that would be icing on the cake. Some compromises for out-of-box ease would be necessary. Make it run on a high-numbered port so any user can run it, and make it easy to reconfig to port 80 if they want to get serious. Choose a database that can be bundled and "just work". Etc. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: enterprise mod_perl architectures
On Wed, Dec 06, 2000 at 01:33:29AM -0500, Ed Park wrote: I've been using mod_perl for two years, and I'm currently particularly interested in: 1) Definitively establishing mod_perl as a credible player in the enterprise space. 2) Discussing enterprise-level architecture considerations, performance benchmarks, development methodologies, etc. You might be interested in the [EMAIL PROTECTED] list Ask mentioned a while ago. It's pretty low traffic, but this lot has the ability to change all of that... http://www.mail-archive.com/modperl%40apache.org/msg11699.html I also am interested in learning from others' battle scars and victories in these areas and a [EMAIL PROTECTED] (as opposed to the advocacy list Stas mentioned) would be interesting, or seeing it here. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
barries [EMAIL PROTECTED] writes: If you could release a source distro of same with a big, red "make" button on it that would allow folks on FreeBSD, debian, wherever to take a stab at it too, that would be icing on the cake. Me too ;-) I mean, what would the damage of a full-on, everything binary be? Ten, twenty megs? OK, so we argue over whether to bundle MySQL or Postgres, but I see no objection to an install that "just works". Especially if there's a whole set of application recipies bundled. -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
Stas Bekman [EMAIL PROTECTED] writes: Yeah, but I don't seem to make other interested. I don't know why. Folks are too busy I guess. It's blogger syndrome. You need to do it in parallel with the development. The only reason my mod_perl/FastCGI comparison got written was because those nice people at EMAP Online let me spend a little time in the office (and a lot more on the train!) to tidy it up. I've got a handler code fragment using the TT that needs tidying up and extending that I think would make a nice little case study. Where should we take this kind of thing? BTW, I tried subscribing to the mod_perl advocacy list: [EMAIL PROTECTED]: Sorry, no mailbox here by that name. (#5.1.1) -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
At 16:39 05/12/2000 -0800, Perrin Harkins wrote: Someone else brought this up with me off the list. Briefly, I said that this doesn't usually happen with web sites for performance reasons and that major RDBMS vendors offer things like two-phase commit. But no, there is no perl transaction service that I know of. You'd have to look at interfacing with a commercial TP monitor for that, and those are more likely to have hooks already written for Java. In which case if that's the only part of the app that requires Java (but the rest is worth doing in Perl) one could simply "use Java;". I haven't really tested it but I've heard that it works really well. -- robin b. You can tune a piano, but you can't tuna fish. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Digest List doesn't show subjects!!!!
Can someone please confirm if this issue is being looked at. The modperl digest list is often very helpful and I would like to keep using it. For at a few weeks now the digest list has been looking like this (no topics are listed): modperl Digest 21 Nov 2000 23:42:00 - Issue 256 Topics (messages 11182 through 11210): (null) 11182 by: 11183 by: 11184 by: 11185 by: 11186 by: 11187 by: 11188 by: 11189 by: 11190 by: 11191 by: 11192 by: etc. etc. Which kind of defeats the object of a digest list, can you please tell me why this is happening and if it can be fixed. (I subscribe to the digest list, because I don't have time to read all the messages on the modperl list, but I would like to be kept up-to-date on what is going on. So I normally just scan the subject headers in the digest to see if anything seems interesting.) Kees Vonk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Dave Rolsky writes: The problem with them compared to mod_perl is that you don't have access to the server internals so you can really only affect the content handling phase. Is this the case with Tomcat as well? I know that you can communicate with the server in the request, it's not totally stand-alone. But I haven't looked into putting in handlers in other phases... -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
I've been following along with this thread with interest, expecially since I'm new to the mod_perl list and community (thanks for all the help so far!). I thought you might be interesed in a 'mod_perl newbie' opinion. Recently I was handed an online event calendar running under CGI and asked to get it to run under mod_perl to speed it up. I'm comfortable with perl, but by no means a guru. And this was the first time using mod_perl. In the past I've used several products which might be considered competitors to mod_perl: Web Objects and Cold Fusion. CF was horrible, I'm glad I didn't have to work with it for long. WO was very nice to work with, and it had all the ecommerce and transation logic needed to build a enterprise web application quickly. (None of my work has been in ecommerce, instead in the medical industry (patient data, lab results, etc) which has many of the same requirements). Installing: I've installed mod_perl twice in the last month. The first time was on Solaris and was quite painless. The second time was on RH 7.0, and was fairly painful. Took most of a day of futzing around to finally get it installed and working. I ran into two problems, first the unrecognized version of apache 1.3.14, and second when I had downgraded to 1.3.12 the new auto-configure part of apache was bypassing the standard Configuration file which mod_perl had inserted itself into, so Apache was building itself without mod_perl. As several others have said here, there is work which could be done in this area. My suggestions would be: - easier install in general (big red button approach is always nice) - make it easier (clear instructions too) on how to configure apache with mod_perl and other modules. The current 'big red button' only works if you have no other modules or already have them configured. - Instructions written for someone who knows nothing about mod_perl, and possible very little about unix. This is a general problem for all open source projects. With today's IT shortage, more and more sys admins are just power users who were promoted or sucked into duties because someone else left. If you want to catch their eye, make sure you talk at their level. I realize this can be a pain in you know where, and it's something that as you look to advocate you need to think about. "Do we want to target everyone, or should there be a minimum level or aptitude before we recommend someone installs this?" Anyone can walk into Staples these days and install Linux. If they have a decent distribution installing everything is easy. But even without a package manager like RH, apache is usually very painless to install. I know a number of non-profits who just have competent users maintaining a Linux server with apache, because for the most part it's trouble free. At worst they might have to restart the server. Technical Issues: The second problem I see with mod_perl is a technical one. Because of the design of mod_perl, debugging problems can be fairly involved. Is the problem my code? Or is it apache, or maybe mod_perl? Could even be perl for that matter. Take for example the problem I ran into recently. (Please don't take this as a rant just because I had problems, I'm happy with mod_perl. But I'm fairly capable around unix and compiling, instead imagine this happening to someone who wasn't that comfortable.) The event calendar works great under CGI, so I try it under mod_perl. It was written to work under mod_perl by a better perl programmer that I'll ever be (Jon Howell of Faq-o-matic fame) and is very well designed. It even worked under mod_perl with some minor changes like supplying the user/pass to the database since it wasn't running under cgiwrap any longer. And it worked! But only 90% of the time. The other 10% of the time, the client received no data, and the page generated by the script ended up in the apache log. After cleaning up one implicit database handle destruction warning the problem persisted, and I began to attempt to discover where the connection was being closed. So I did what any lazy programmer does, I added some print statements to send a note to STDERR. While these all showed up when the program worked correctly, when problem occured, the prints to STDERR dissapeared. But the html page was printed to the apache log, basicly standard error. So it looks like if the socket is closed, stderr dissapears, and stdout goes to the error log. So no pointers appeared in the log, which wasn't very helpful. Next attempt was to do some packet sniffing to see why the socket was closeing. Turns out that the web server sends an orderly release indication (T_ORDEL_IND = 132), so the client being a good citizen reponds with a orderly release request and there goes the socket. While my description of the problem was more in-depth that I meant it to be, my point is that now I'm left with the need to trace through system calls made by apache, mod_perl and my program to try and find
HTML::Template - cant use shared cache with global_vars?
Hi. I'm using HTML::Template v2.0, IPC::SharedCache 1.3, IPC::ShareLite 0.08, Storable 1.0.6. I've discovered that if I turn on the "global_vars" option in HTML::Template, then Storable cant serialize the template so that it can be placed in the cache. e.g.: my $tmpl = HTML::Template-new_file( 'foo.tmpl', associate = $cgi, global_vars = 1 ); Then when this code runs, it crashes with: [Wed Dec 6 09:38:49 2000] [error] Can't store CODE items at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/_freeze.al) line 234, at /usr/lib/perl5/site_perl/5.6.0/IPC/SharedCache.pm line 554 If I simply turn off global_vars, then everything works fine. Has anyone else experienced this? I would like to be able to use global_vars and shared_cache at the same time :). Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache 1.3.14 build
"WP" == Wang, Pin-Chieh [EMAIL PROTECTED] writes: WP I am trying to build apache v.1.3.14 with Mod_perl v. 1.24 using APACI WP I am using Perl 5.6 build 620 - the latest Try using the latest mod_perl as well. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
I've always considered mod_perl similar to an artist's canvas, while Java is more like a craftsman's tool kit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matt Sergeant wrote: On Tue, 5 Dec 2000, Jeffrey W. Baker wrote: With J2EE you get the complete illusion that you are doing txns across as many data sources on as many systems and vendors as you want, but behind the illusion there is the nonzero risk that the data is inconsistent. In a real transactional system, you can never have inconsistent data. This thread is suffering from a severe lack of technical information. Can you go into more technical detail on what that 0.01% is (and is caused by)? Yup. Machine A is controlling a transaction across Machine X and Machine Y. A modifies a row in X and adds a row to Y. A commits X, which succeeds. A commits Y, which fails. Now what? A cannot guarantee a recovery on machine X because there might already be other transactions in flight on that record in that database. A cannot just try to put the record back the way it used to be, because now the commit might fail on X. The data is inconsistent. The only thing that Machine A can do now is send an email to the DBA explaining what happened and what was supposed to happen. "Fucking Hell" says the DBA, under his breath. -jwb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
www.modperl.com
I regret to say that www.modperl.com is down again. This time it is because someone broke into my house and stole some computer equipment, including the DSL router. Fortunately the modperl web server itself was untouched because it was hidden in the eves. I will make an announcement when the system is back up. Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Gunther Birznieks wrote: Has anyone written a Perl IDE in Perl? i goofed around with a class browser/code generator a while back, but i lost interest. as i recall, #perl laughed at me when i suggested it :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matt Sergeant wrote: You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. that's why Bundle::AO is nice. it's stubborn adherence to models like this, tho, that keeps us from making generational advances rather than incremental ones. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matt Sergeant wrote: I quite like the Zope model - a single distribution which just includes and installs everything you need in a single place. You get python, the httpd, the database, everything. Of course if you have more complex needs, like running Zope from within Apache, you need to do some extra work, but out of the boz Zope gives you a great system that just runs. We could do that with AxKit - just ship it with Apache, mod_perl, the whole lot. But I don't think that would appeal to Perl people somehow. Thoughts? this is how we ship our products internally at cpth. we build perl, apache, 100 or so modules, and ~150 registry scripts. then we rpm the whole thing up. the operations team just has to: rpm -i /usr/local/webmail/current/bin/wmctl start. doing something like that doesn't play nice with the os vendor distributions really, but some people might like it. another option would be to use autoconf. wrap a configure script around your entire set of components. allow it to find and use whichever ones you've already got installed. have it build and install whatever you don't already have. not very tough. also not very portable to windows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Jim Woodgate wrote: I know that you can communicate with the server in the request, it's not totally stand-alone. But I haven't looked into putting in handlers in other phases... i believe with mod_jk there is a callback model, yes. but given tomcat's valve architecture, i don't see much need to call back into apache at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, brian moseley wrote: On Wed, 6 Dec 2000, Matt Sergeant wrote: You can't, but thats because I believe in the CPAN model - use pre-written components. I don't believe shipping all those components in AxKit (and there are a fair number required) is the right solution. Maybe I'm mistaken. that's why Bundle::AO is nice. What does Bundle::AO give you that setting PREREQ_PM correctly wouldn't? it's stubborn adherence to models like this, tho, that keeps us from making generational advances rather than incremental ones. Agreed... I *do* wish that more perlers would be open to binary modules - the Activestate PPM model. While there were regularly problems with PPM, the vast majority of module installations were incredibly trivial. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Newbe - APXS install problem
Apache with mod_perl (built with APXS) fails to start with this error: Cannot load /opt/WWW/libexec/libperl.so into server: dynamic linker: /opt/WWW/bin/httpd: relocation error: symbol not found: Perl_sv_free Apache rev = 1.3.14 mod_perl rev = 1.24_01 perl rev = 5.00503 OS = dynix/ptx rev 4.4.6 on an IBM NUMA (A UNIX system SYS-V Rev 4 with some Berkely Apache has the "mod_so.c" compiled in module and is statically built The missing function "Perl_sv_free" can be found in the main Perl library /usr/local/lib/perl5/5.005.3/i386-dynixptx/CORE/libperl.so. (Found by "nm") Setting LD_RUN_PATH, LD_LIBRARY_PATH and even LD_LIBRARY_PRELOAD to the mod_perl and the perl library paths, does not help, nor change the error message. Josh Goldberg Tel: 646-497-4214 Fax 646-497-4200 E-mail [EMAIL PROTECTED] This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. All e-mails at Neuberger Berman are, in accordance with Firm policy, to be used for Neuberger Berman business purposes only. E-mails sent from or to the Firm are subject to being reviewed by the Firm in accordance with the Firm's procedure for the review of correspondence. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
su - bin ./install.all
I have a shell script that runs as bin and installs, on /opt, everything (zlib-1.1.3,perl-5.6.0,openssl-0.9.6, mm-1.1.3,modssl-2.7.1,mysql-3.23.28-gamma, modperl-1.24_01( apache_1.3.14 via apaci)) one would need, EXCEPT it needs some expect scripts (I expect) to ftp the sources files in and download needed modules from CPAN. I have a fair, dependency ordered, perl module list to get a html::mason site running. The MySQL debian binary has a ton of flags, I need to, for instance, determine what arch/os combos can take which flags. It will work with a very basic tasksel(ection) list, but I don't know how basic. I don't know Expect. -JoshNarins - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
eval statements in mod_perl
Howdy,
I am running mod_perl and have created a handler that serves all the
pages for our intranet. In this handler I load perl programs from file into
a string and run eval on the string (not in a block). The problem is that
for any session the code doesn't work the first or second time, then it
works fine. Is this a caching issue or compile-time vs. run-time issues? I
am sure this is a simple fix. What am I missing?
Here is the nasty part (don't throw stones :) So that we can
develop, I put the eval in a loop that tries it until it returns true or
runs 3 times. I can't obviously leave it this way. Any suggestions? Here
is the relevant chunk of code:
# Expect perl code. Run an eval on the code and execute it.
my $evalcode = "";
my $line = "";
open (EVALFILE, $build{"$nkey"});
while ($line = EVALFILE) {
$evalcode .= $line;
}
my $evalresult = 0;
my $counter=0;
#
# Temporary measure to overcome caching issue, try to
#
# run the eval code 3 times to get a true return.
#
#
until (($evalresult) || ($counter eq 3)) {
$evalresult = eval $evalcode;
$counter++;
}
$pageHash{"Retries"} = $counter if $counter 1;
$r-print($@) if $@;
close (EVALFILE);
I appreciate any and all constructive comments.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matt Sergeant wrote: What does Bundle::AO give you that setting PREREQ_PM correctly wouldn't? i don't know :) i use them both. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
This debate has really hit some hot buttons. I love reading the exchanges as there are clearly some personal philosophies at work here. Ain't it great! "Michael" == Michael Robinton [EMAIL PROTECTED] writes: Michael Give a man a dump truck full of leggos, motors and gears Michael and you can build some really interesting stuff, give man Michael an end mill or a lathe and he can build a rocket ship to Michael the moon. You figure out which one is Weblogic and which Michael one is Apache-modperl :-) Doubtful. In my experience, these so-called enterprise solutions are just that ... a huge lathe, or whatever an end mill is. Their solution to even the most minute problem is to throw huge - I mean huge - application piece parts at it, hoping to bury it in the wizard technology of the moment. There is no other solution. You get it all or you get none of it. Or if you only want a part of the bulk, you still must sift through a mountain of installed crap. "What do you mean I need 1GB of disk and 500 MB of memory just to get an internet-enabled report queue manager?" Now maybe some feel better with a large enterprise application server or whatever staring over one's shoulder, but I prefer to build my solution in a way that I get only what I need. The rest can be called upon, installed if you will, when it is deemed necessary (by me, or by the needs of the environment), but otherwise only the necessary parts are present and in play. And I can determine what is necessary and when, not the vendor supplying the solution-of-all-solutions. Apache/mod_perl has enabled my team and I to craft finely detailed modules that I can apply to specific problems in my intranet environment. I can bring to the battle one, some, or all of mod_perl's intrinsics coupled with the vast CPAN, tightly woven with modules of An enterprise-size solution is rarely a viable answer to an enterprise-size problem. JM.02W Peace. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Dec 05, Greg Cope wrote: But, you all know that php pretty much takes over. Why? For two reasons: 1) initial corporate pushing (press/ads) 2) once well known, the word of the mouth does the rest. Well go back 2 / 2 1/2 years and PHP was little known. what is even funnier is that if you go back that far and look at the php mailing lists back then, you'll find the exact same conversations. :) how did php become so popular? so many hosting companies offered it as part of their hosting. fortunately for php, it targets a bit more of a niche (generating dynamic content) than mod_perl does (writing apache modules in perl) so offering it as part of a hosting package on shared servers is quite a bit easier. (of course, this only addresses scaling to a breadth of users, not scaling into the enterprise area. that just requires real marketing and hype.) jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: enterprise mod_perl architectures
On Wed, 6 Dec 2000, Ed Park wrote: The project that I propose is simple and concrete: create an open forum in which all of the folks who are currently undergoing the same growing pains that we are, or who have been through them already, or who are otherwise [...] The scalable list is for you. try [EMAIL PROTECTED] and look at http:[EMAIL PROTECTED]/ - ask -- ask bjoern hansen - http://ask.netcetera.dk/ more than 70M impressions per day, http://valueclick.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, brian moseley wrote: [...] this is how we ship our products internally at cpth. we build perl, apache, 100 or so modules, and ~150 registry scripts. then we rpm the whole thing up. the operations team just has to: rpm -i /usr/local/webmail/current/bin/wmctl start. that's what we do at ValueClick too, (except using a tiny script that configures a perforce view and does a perforce sync instead of the rpm). doing something like that doesn't play nice with the os vendor distributions really, but some people might like it. for applications that are complex enough[tm] it makes sense to install your own perl, apache, everything. For everything else it's bloat and just a waste. another option would be to use autoconf. wrap a configure script around your entire set of components. allow it to find and use whichever ones you've already got installed. have it build and install whatever you don't already have. not very tough. also not very portable to windows. and doesn't work (or get's complex fast) if it needs, say, /usr/bin/perl but with -Duselargefiles and the already installed stuff needs it without. - ask -- ask bjoern hansen - http://ask.netcetera.dk/ more than 70M impressions per day, http://valueclick.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validating Parsers
hello Does anyone know of a xml parsing module that validates using built-in functionality, or is there a method to validate xml using XML::Parser with another module? -- Mail: [EMAIL PROTECTED] Area: Web Development (Developer) Date: 06-Dec-00 Time: 10:47:13 The most powerful bill paying tool ever created! -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
On Wed, 06 Dec 2000 05:52, Matthew Byng-Maddick wrote: 6. Engineering The Perl community is made up of a truly eclectic group of people, which is an amazing strength. However, it's also an amazing weakness: I get the impression that very few programmers in the Perl community spend a lot of time *reading* books on software engineering and techniques thereof... and I'm not convinced about this. Although from my limited experience, I'm not very fond of them Hmmm, I'm not sure if you're talking about the programmers or the books. Ha. But seriously, I lose a lot of respect for people who don't continually study software engineering yet call themselves developers. Our craft is constantly evolving, and to ignore the material that's available to us to learn new techniques is completely irresponsible and it leads to some of the problems that we are bemoaning in this very thread. that lack of knowledge tends to bleed over into a lot of code out there. We have a HUGE problem in the community of the "coder superstar" mentality... yup. which is very dangerous. Perl allows far too many tricks, and often code ends up totally unmaintainable and unreadable because some coding yahoo put in some glory-code. It happens in many languages, true, but Perl is the ideal environment for it. Not necessarily. You can get coder superstars who write maintainable and understandable code. OK, terminology problem... I wouldn't call them "coder superstars" *if* they write maintainable and understandable code. Perhaps I should have called them "glory coders" instead. You're totally right, there are plenty of great coders out there who conform to coding standards and don't write tricky code. But what I mean is that there is an abundance of glory-coders in the Perl community because, in a way, the community encourages it. That doesn't fly in a large-scale project and greatly reduces the chances of mod_perl being adopted in the enterprise (IMHO). * We implement a "mode" under mod_perl, kind of like "use strict", that suddenly forces Perl to behave well from an object-oriented standpoint. By this, I mean taking some of the power away from Perl that causes trouble, like allowing anyone to write instance data on an arbitrary instance of a class... No. no no no. Forcing perl to behave as "Object oriented" is entirely the wrong thing. This is why Java sucks so much. "Everything is an object" (excepting, obviously, the language primitives). Perl is nice because you can write it functionally or object oriented depending on the problem you're trying to solve. Also this functionality is more core Perl than mod_perl. Ok, you're missing my point but that's partially my fault for not explaining. First, let me agree: Java's "everything is an object" mentality sucks balls. And yes, Perl's duality of functional/OO is really nice. Taking that away is not what I am advocating... I think there should be the *option* in Perl to disable certain features that make Perl a dangerous language for OO development. First and foremost, the lack of true encapsulation is disastrous. There is no concept of private data because instance data is stored in a blessed hash (typically) that's open wide to the world. It makes it tough to create a true interface/implementation dichotomy that is important in the OO world. * We "homogenise" some foundation classes. This means we create a *suite* of classes that have consistent API, are designed together as a framework, and are easy to learn I think you need to get out of the "object-oriented-only" mentality. But yes, sort of, agreed. U, remember, this thread is about mod_perl advocacy. In my mind, we will have huge problems encouraging enterprise adoption of mod_perl without some fundamental changes. No enterprise in its right mind would choose a platform that is not OO for any large project these days. Regardless of whether you like this or not (and I can tell that you don't), it's the truth... you said it yourself. In order to fight the Java juggernaut, we have to beat them at their own game. Perl has so many advantages over Java that that shouldn't be a problem, yet it is. Primarily, it's one of perception... Perl is a scripter's language, Perl is for hackers, Perl is great for sysadmin tasks... but it's also a technical one. Java has a set of foundation classes that everyone uses. They suck festering balls, but they're there. We can learn from that and build a set of consistent classes that allow developers to build web *apps*, not a shitload of scripts that kinda work together as glorified CGI, which is what we get all too often now. Yes, Java is a sorely broken language, but it's being adopted, partially because of Sun's hype but also because it offers enterprise developers real ways to encapsulate their business logic properly. There are a few reasons why mod_perl can't fill the
[OT] shmget? [Was: mod_perl advocacy project resurrection]
--- Gunther Birznieks [EMAIL PROTECTED] wrote: [re: Java] 1. Trivial to do multithreading and shared memory (in a single server). Really nice for pools of cached information. Single process model sucks for this. Can't say I've looked, but has no one put a nice class wrapper around shared memory in Perl? __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Smart installing (Re: mod_perl advocacy project resurrection)
On Wed, 6 Dec 2000, brian moseley wrote: another option would be to use autoconf. wrap a configure script around your entire set of components. allow it to find and use whichever ones you've already got installed. have it build and install whatever you don't already have. not very tough. also not very portable to windows. Perhaps part of this is that we simply need smarter configure/install methods. There are many limitations imposed by the Perl MakeMaker stuff, a lot of which I have run up against trying to get Alzabo (which is part modules, part mason components, and also needs a place on disk to store info) tested and installed properly. I've also dealt with this on another app I'm working on (currently under NDA) that requires a bunch of modules, a set of tables in a database, mod_perl, etc. I keep meaning to look into cons. Perhaps that is the way to go? For example, perhaps all modules should check for the prerequisites on their own and attempt to use CPAN to fetch them if they can't find them. That works great if the person installing has already config'd the CPAN module but if not it'll ask you a lot of questions, which may be annoying. Is there a better way? I'm pretty sure there is. The problem is right now all my solutions are pretty much ad hoc (package MY up the wazoo). It would be nice to get something a lot smarter going. This is semi-offtopic but does relate the 'untar and go' concept. I don't think that that is all that likely. But 'untar, run configure, answer some questions, and go'. That would be a great goal, as opposed to 'untar, try to install, realize you're missing five pieces, install those pieces, try to install, realize you missed something else, install it, try to install once again, get it installed, tweak three config files, manually start up the server with the right switches, and go!' But I'd also like to point out, as Matt Sergeant said, this stuff is _really_ hard, and not very glamorous. I would've done much less of it except for the fact that I'm being paid to do it for the above-mentioned NDA'd project. I do it for Alzabo because I feel strongly enough about its potential to try to make it more seemless than your average Perl module/app. -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
--- "Jeffrey W. Baker" wrote: Yup. Machine A is controlling a transaction across Machine X and Machine Y. A modifies a row in X and adds a row to Y. A commits X, which succeeds. A commits Y, which fails. Now what? A cannot guarantee a recovery on machine X because there might already be other transactions in flight on that record in that database. A cannot just try to put the record back the way it used to be, because now the commit might fail on X. The data is inconsistent. --- end of quote --- You can buy a solution to that. High-priced java application servers like iPlanet's call this "two-phase commit" and hide it behind JTA (using IBM's Encina engine in this case). For only $35k per CPU. There must be a CPAN module for it. ;) -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[entirely OT :o] Version 0.3? [Was: mod_perl advocacy project resurrection]
--- Perrin Harkins [EMAIL PROTECTED] wrote: you don't have to spend time re-integrating Apache::Session and Apache::DBI and Apache::WipeMyAss with each new project. I think Apache::WipeMyAss auto-configures as of 0.3. Where can *I* get that upgrade? =o) __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, Dec 06, 2000 at 04:55:37PM +0800, Gunther Birznieks wrote: Has anyone written a Perl IDE in Perl? Tom Christiansen wrote an IDE-like lash-up of vi and perl, IIRC, but I don't recall the specifics and I can't find in on-web right now. You might search the perl5-porters archives for mention of it. It certainly doesn't have the forms-based programming model that many people mean when they say "IDE", but under Unix, lots of editors have the compile-execute-tweak cycle semi-automated (which is what I think of when I hear "IDE"). Some could have GUId for the perl debugger, I don't know. There are various such GUI front ends floating around, FWIW. Codewrite and NEdit are pretty good alternatives on Windows that might qualify as IDEs, depending on your definition. (NEdit is very multiplatform, too) if that's where you code Perl. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
all DSO but STATIC MOD_PERL: apache1.3.4/modperl1.24_01/perl5.6.0/Solaris 5.6
Hi! Can someone point me to what I am missing? I tried guide messed with the following 1/2day, but still no clue. 1) If I configure Apache by itself: solaris:~/src/apache_1.3.14 707# ./configure --enable-module=most --enable-shared=max --enable-rule=SHARED_CORE and then make install, I end up with a working Apache. However, if I do it with mod_perl in as close way as possible, aiming for *static* mod_perl, here is what goes on (make distclean done in ~/src/apache_1.3.14 and ~/src/mod_perl-1.24_01 prior to any configure invokations): solaris:~/src/mod_perl-1.24_01 711# perl Makefile.PL APACHE_SRC=../apache_1.3.14/src USE_APACI=1 EVERYTHING=1 APACI_ARGS='--enable-module=most --enable-shared=max --disable-shared=perl --enable-rule=SHARED_CORE' Will configure via APACI Configure mod_perl with ../apache_1.3.14/src ? [y] Shall I build httpd in ../apache_1.3.14/src for you? [y] ... make then succeds. 2) However, make test fails in the following way: cp t/conf/mod_perl_srm.conf t/conf/srm.conf ./apaci/load_modules.pl ../apache_1.3.14/src ../apache_1.3.14/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 Syntax error on line 2 of /home/vassilii/src/mod_perl-1.24_01/t/conf/httpd.conf: Can't locate API module structure `httpd_module' in file /home/vassilii/src/mod_perl-1.24_01/t/../../apache_1.3.14/src/libhttpd.so: ld.so.1: ../apache_1.3.14/src/httpd: fatal: httpd_module: can't find symbol I tried to do make install from ~/src/mod_perl-1.24_01 and/or from ~/src/apache_1.3.14, but the tests still don't run and my server is inoperational that way. 3) W/o any DSO involved, everything goes just fine -- when configured with solaris:~/src/mod_perl-1.24_01 711# perl Makefile.PL APACHE_SRC=../apache_1.3.14/src USE_APACI=1 EVERYTHING=1 APACI_ARGS='--enable-module=most' A) Misc versions numbers: + apache_1.3.4/mod_perl-1.24_01 + all the prerequisite Perl modules (LWP etc.) are current (CPAN doesn't suggest upgrade) + perl -V: Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=solaris, osvers=2.6, archname=sun4-solaris ... Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-E -R /usr/local/lib/perl5/5.6.0/sun4-solaris/CORE' cccdlflags='-fPIC', lddlflags=' -W,l-E -G -L/usr/local/lib -L/opt/local/lib' ... + gcc 2.8.1 + the compiler used for perl build is the very same compiler as for the Apache/mod_perl build Vassilii http://www.tarunz.org/~vassilii/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
At 14:07 06/12/2000 -0500, kyle dawkins wrote: Ok, you're missing my point but that's partially my fault for not explaining. First, let me agree: Java's "everything is an object" mentality sucks balls. And yes, Perl's duality of functional/OO is really nice. Taking that away is not what I am advocating... I think there should be the *option* in Perl to disable certain features that make Perl a dangerous language for OO development. First and foremost, the lack of true encapsulation is disastrous. There is no concept of private data because instance data is stored in a blessed hash (typically) that's open wide to the world. It makes it tough to create a true interface/implementation dichotomy that is important in the OO world. That's because of the way most people implement their classes. Perl does have a concept of private date (although it's not built into the language as that) and it's actually fairly easy to get that. OO Programming with Perl by Damian Conway has plenty of example demonstrating that. I also have an inheritable Class::ArrayBased somewhere on my disk that provides a framework for array based objects. Admittedly it's encapsulation through obscurity (so to say) but people that understand how it works will probably respect the encapsulation, while those that don't will fail to access the content as a hashref. -- robin b. Make it idiot proof and someone will make a better idiot. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
--- Chris Winters [EMAIL PROTECTED] wrote: [...] 'Java' and 'open-source' are not mutually exclusive :-) Hallelujah! I still prefer Perl, but this is news to me, and GOOD news! =o) [...] And the perception out there, unlike with mod_perl, is that you don't need to be a wizard to build such applications. Maybe that's because there are more books, maybe that's because of the marketing machine, maybe that's because IDEs will give you some hand-holding along the way -- I dunno. I think a lot of that convenience is built into the Java straightjacket, but I will admit that, in a broad production system, I'd probably be more willing to wear that straightjacket to make sure I didn't bring the server down. Java is built for safety. I may not like it, but it's valid. I just prefer Perl. Still, (mod_)perl advocacy should provide more and better (mod_)perl tools. Both languages are evolving; Larry's putting Unicode and Threads into the next Perl, right? Java regex's are improving, yes? We advocate (I will still support Java and Python and x,y,z, but mostly Perl) to build our resource base. A bigger, better, cleaner, easier pool of tools means a bigger, better, cleaner, easier language, and the cycle goes 'round. __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [entirely OT :o] Version 0.3? [Was: mod_perl advocacy project resurrection]
On Wed, Dec 06, 2000 at 11:14:46AM -0800, Paul wrote: --- Perrin Harkins [EMAIL PROTECTED] wrote: you don't have to spend time re-integrating Apache::Session and Apache::DBI and Apache::WipeMyAss with each new project. I think Apache::WipeMyAss auto-configures as of 0.3. Where can *I* get that upgrade? =o) I think you will need to install Apache::KissMyRedEye to make that module work. JJ -- J. J. Horner [EMAIL PROTECTED] "The people who vote decide nothing. The people who count the vote decide everything." - Josef Stalin "The tree of liberty must be watered periodically with the blood of tyrants and patriots alike. ... Resistance to tyrants is obedience to God." - Thomas Jefferson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
brian moseley wrote: On Wed, 6 Dec 2000, Gunther Birznieks wrote: Has anyone written a Perl IDE in Perl? i goofed around with a class browser/code generator a while back, but i lost interest. as i recall, #perl laughed at me when i suggested it :) ActiveState has built an Perl/Python IDE out of Mozilla: http://www.activestate.com/Products/Komodo/index.html -- Matthew Kennedy Opus Healthcare Solutions, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Hi there, This isn't a silly question. At least I hope it isn't. On Wed, 6 Dec 2000, Jeffrey W. Baker wrote: [snip,snip] A modifies a row in X and adds a row to Y. A commits X, which succeeds. A commits Y, which fails. The only thing that Machine A can do now is send an email to the DBA "..." says the DBA, Given that it's designed to fail sooner or later, are there good reasons why someone would put together a system in that way? 73, Ged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matthew Kennedy wrote: ActiveState has built an Perl/Python IDE out of Mozilla: http://www.activestate.com/Products/Komodo/index.html too bad it's windows only :/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
shared mem [was: mod_perl advocacy project resurrection]
--- Jim Woodgate [EMAIL PROTECTED] wrote: [...] 2) Sharing information between the processes. There's lots of different ways to do it, but none really jumps out as an end-all solution. Is there no Apache::SharedMemory (or some such)? If not, does anyone think it would be worth the time for someone (like me) to sit down and write it? (Couldn't it be done?) The parent process could declare a shared memory segment at boot time. Each child's init could spawn a shared memory interface object. Wouldn't that allow for some resource pooling to be cleaner? How would that interact with per-child namespaces (if at all)? Is there a reasonably safe and useful way for one process to open a resource (like a DBM or database handle) and then expose it to another process through a shared memory segment? __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
at a time earlier than now, Dave Rolsky wrote: On Wed, 6 Dec 2000, brian moseley wrote: But I'd also like to point out, as Matt Sergeant said, this stuff is _really_ hard, and not very glamorous. I would've done much less of it while the install and auto configure part is not very glamorous, the possibility of being able to untar one package to get mod_perl w/ persistent db connections, transaction management, data relational modeling/objects and a nice templating/servlet engine is very glamorous! you could be a folk hero! honestly it seems like a pretty worthwhile project to me. basically, what is missing is (cough! cough!) simply a lot of hard work. except for transaction management, which is apparently of questionable value, all the pieces exist, right? database abstraction and connection pooling = DBI session management = Apache::Session load balancing = mod_backhand?? data relational mapping = Tangram or Alzabo templates or whatever you want to call them = HTML::Embperl/Mason/TemplateToolkit ide = pick an editor with a few hooks to call make, install and restart granted this may not get us everything, but if we could package up the stuff we all use over and over again, wouldn't that get us pretty far? Aaron I'm willing to contribute time to this project if given some input on how to proceed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
"Bruce W. Hoylman" wrote: snip In my experience, these so-called enterprise solutions are just that ... a huge lathe, or whatever an end mill is. Their solution to even the most minute problem is to throw huge - I mean huge - application piece parts at it, hoping to bury it in the wizard technology of the moment. There is no other solution. You get it all or you get none of it. Or if you only want a part of the bulk, you still must sift through a mountain of installed crap. "What do you mean I need 1GB of disk and 500 MB of memory just to get an internet-enabled report queue manager?" I don't know where you got the 1GB disk requirement from? Even Weblogic's download is only 43Mb, jBoss' is about 6Mb. The Java Platform is somewhere between that. Your compiled enterprise app might only be 300Kb (and not just a "report queue manager"). And 500Mb of memory? That's tuppence in the server world anyway. J2EE is such a joy to work with in these class of problems which require a middle tier. The APIs are clearly defined and standardized, every object has a consitent feel, low level issues such as socket communications and threading is handled for you. It leaves the developer free to actually code toward the solution. Now maybe some feel better with a large enterprise application server or whatever staring over one's shoulder, but I prefer to build my solution in a way that I get only what I need. The rest can be called upon, If you think you can hack out a solution for those class of problems from CPAN, then good for you. I'm sure you can in some cases. I think mod_perl has done an excellent job of conquering the the two-teir web-based problems. I love tools such as Mason and Apache::ASP which ride on mod_perl. Perl-DBI is an excellent advancement for Perl in general also. I think it's exciting to think what an n-tier framework in Perl might look like. IMHO, it should be more than just the outgrowth of CPAN's contents. snip An enterprise-size solution is rarely a viable answer to an enterprise-size problem. Sounds almost like you're talking about "enterprise" being a "company"? I know you can't be though... right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Perhaps part of this is that we simply need smarter configure/install methods. ... I've also dealt with this on another app I'm working on (currently under NDA) that requires a bunch of modules, a set of tables in a database, mod_perl, etc. I've been dealing w/ very similar issues in work I'm doing. I've got: * Perl modules * command line tools * database tables * data files * custom configuration * other open-source distributions and more, and it's all got to be installed in the right place, and the Right Thing has to happen if some pieces are already installed, etc. My "solution", so far, is a custom install script. Rather than trying to hack everything into MakeMaker and make it work through some deep magic, I'm writing an install script that's a layer above the MakeMaker stuff: I still let MakeMaker do its job w/ the Perl modules, regression tests, etc. But so far I've ended up writing my own code for everything else. And that's partly why it's not done yet. :) I also mean to investigate cons. bye, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
modperl digest subjects broken
List manager, I truly enjoy mod_perl. I enjoy just as much the numerous ideas and technologies that the mod_perl list exposes me to. However, I number amongst those that cannot handle the numerous list e-mails, and therefore rely on the digest. Unfortunately, the digest function appears to be partially broken. As is illustrated below, the subjects are not being included in the Topics section. I have noticed that 2 or 3 ppl have made this complaint before - I believe the first on Nov. 28th, and the most recent on Dec. 4th. However, there has yet to be any feedback (or at least, I could find no evidence in the mail archives.). I am assuming that this is a problem w/ the list software - if this is the case, is there a fix planned for this problem? thanks, -john marquart ---Illustration of what is being recieved in the digest--- modperl Digest 5 Dec 2000 23:42:00 - Issue 271 Topics (messages 11622 through 11660): (null) 11622 by: 11623 by: 11624 by: 11625 by: ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
"Gunther" == Gunther Birznieks [EMAIL PROTECTED] writes: Gunther This is exactly why someone experienced in training (ie Gunther Randal/StoneHenge) would hopefully be the ones to take the Gunther torch on this. If there's anyone I would trust a Gunther certification from, it would be them. We've considered the certification route from time to time, but other than being a money maker for us (which isn't all that bad of a deal :-), I'm still not entirely convinced that the community of *ours* would demand certification in any distinguishing way. I mean, until I can demonstrate that people with certs are likely to get hired faster or make more money, what's the point? As it is now, good mod_perl people are hard enough to find that the jobseeker already has the advantage. I'm very open to being convinced otherwise though. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Debugging Apache::ASP
"Differentiated Software Solutions Pvt. Ltd.," wrote: Hi, We've been using Apache::ASP over the past one month. We are having problems debugging an ASP program. We have set the debug level to 3 but still. At debug level 3, the line in which the error occurs is displayed. But if we have multiple statements withing % and % tags then, the error display only gives only one line number (line number of the first statement) is displayed. We are finding it very difficult to identify the exact line where the error has occured. In general we find Apache::ASP support for debugging quite poor. Are there any tools which we are missing out ?? How do others tackle this ?? How do people track "use of uninitialised variable". Don't do "use strict", do PerlSetVar UseStrict 1. Use Apache::ASP v2.03 or greater as it had significant debugging enhancements. If you are having problem with your debug output, let me see it, and I may be able to help interpret. The line numbers are usually right on. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Ged Haywood wrote: Hi there, This isn't a silly question. At least I hope it isn't. On Wed, 6 Dec 2000, Jeffrey W. Baker wrote: [snip,snip] A modifies a row in X and adds a row to Y. A commits X, which succeeds. A commits Y, which fails. The only thing that Machine A can do now is send an email to the DBA "..." says the DBA, Given that it's designed to fail sooner or later, are there good reasons why someone would put together a system in that way? There's probably no reason one would _design_ a system like that per se. However there are plenty of times it just _turns_out_ like that -- usually as the result of a system evolving through time. Another example might be the B2B case of consulting your own DB etc. and then communicating some change based on that to another organization's DB system. I've seen that particular situation arrise many times. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
be nice reminder [Was: mod_perl advocacy project resurrection]
While we're on the topic of advocacy, I'd like to briefly mention the RTFM reflex. Most of the people working on these projects are *working*. They have no time to coddle stupid questions from newbies who didn't *bother* to RTFM. I do understand that, and I sympathize. But if we're talking advocacy, I must point out that as a newbie, my biggest problem was finding out where to look to *find* the manual. Also, when I was trying to get this system working ~now~, (the "out-of-the-box" problem we keep seeing), it was frequently important that I get answers quickly, and though I hated to bother the list with mundanities, it was a lot faster to ask (and get a response amid the RTFM's) than to read through a dozen documents to find where the information I needed, especially when it was ditributed among three or four of them and I needed to understand the relationships before it made any sense. I know improving the quality and interrelatedness of our documentation is an ongoing effort, but though I have most often seen a very helpful and friendly attitude towards (yes, even stupid) questions, I remind us all that one "RTFM and quit wasting our time, jerk" response will sour someone on the ENTIRE language, and that the someone might always have been the next Bill Gates looking for a tool to sponsor Personally, I know that I'm less qualified for the in-depth questions, so I tend to *look* for the misplaced and ignorant requests. Explaining how to access an entry in a hash isn't worth a lot of people's time -- but I see those people occasionally spend the time to point that out. While we're at it, let's always take the extra few seconds to be *nice* about it, and at least make a token effort while we mention that there's a better forum for that at [EMAIL PROTECTED] Kudos to those of you who have consistently shown that patience, and raspberries to those who haven't. :op (thpbpfhtbphff!!!) And again, finally, many thanks to all of you who have nudged me each time a little closer towards competency. Yopu folks are another reason I like Perl. ;o] __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
At 12:39 06/12/2000 -0800, brian moseley wrote: ActiveState has built an Perl/Python IDE out of Mozilla: http://www.activestate.com/Products/Komodo/index.html too bad it's windows only :/ That's bound to change. I think AS will release it on all platforms where Moz/Perl/Python run when it's finished. The current release is very unstable anyway. -- robin b. All paid jobs absorb and degrade the mind. -- Aristotle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
On Wed, 6 Dec 2000, Aaron E. Ross wrote: while the install and auto configure part is not very glamorous, the possibility of being able to untar one package to get mod_perl w/ persistent db connections, transaction management, data relational modeling/objects and a nice templating/servlet engine is very glamorous! you could be a folk hero! Well, while I'd like to masses to speak my name in legend and song, I've also got a lot on my plate ;) Seriously, I'm less interested in a unified package (I think Brian is working on that) than an intelligent system for doing configuration of modules/apps. For example, for one project I'm working on, I've had to do a fair amount of work to get it to try to find an existing mod_perl enabled Apache server and then to check whether or not the server is the right version of Apache and mod_perl. This kind of work would probably be useful in a more generic form. Some of this work is already in the Apache::test module, which can analyze a server and its configuration and find some useful info. Enhancing this module to really be able to give a lot of details about an existing install would be very useful. This would certainly be handy for the all in one system you describe (which is what Brian's aiming at for AO, if I'm not mistaken) but also for any other large mod_perl using app. Similarly, a mechanism for packaging tests to be done against a database would be useful (something I've worked on for Alzabo). Like I said, I really need to examine cons and see if it can help with all this. The problem being that most people don't have cons installed (although it can always be included in a package). -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: shared mem [was: mod_perl advocacy project resurrection]
Hi Paul, On Wed, 6 Dec 2000, Paul wrote: Is there no Apache::SharedMemory (or some such)? If not, does anyone think it would be worth the time for someone (like me) to sit down and write it? (Couldn't it be done?) There be dragons. 73, Ged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::ASP problem with post data
Luc Willems wrote:
hello ,
i'm working on a project that involves some XML-RPC system. The idea is
to POST a XML to a ASP script which will than process this
and return a XML back to the client.
To do that a send sommething like this (output from ethereal dump) :
POST /cp-bin/rc2.asp HTTP/1.0
Host: linux
User-Agent: libwww-perl/5.36
Content-Length: 156
Content-Type: text/xml
?xml version="1.0"?
methodCall
methodNameexamples.getStateName/methodName
params
paramvaluei41/i4/value/param
/params
/methodCall
The problem now is , that in the asp script i get a Totalbytes of 156
bytes but the content string is empty ?
I don't know why this is happening. Everything looks like it
should work fine. Can you write a mini Apache::Registry script
with the same call to it, and do:
print Apache-content();
In Apache::ASP, content is initialized like:
$self-{content} = $r-content();
very straightforward, so if the above shows content, but
Apache::ASP isn't getting any, I'll be a little stumped.
Also, what is the output from:
%= $Request-BinaryRead() %
which should return all of the output. Your other code should
have worked, but just in case. BinaryRead w/o a length just
returns all of it.
This shouldn't be the problem, but is there the chance that
there is something else calling $r-content() first? Maybe
some other code in another PerlHandler stage? This should
not be the problem because one would expect your script to hang
in this case, but again I'm a bit stumped.
-- Josh
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
(not strictly modperl) how do I tell if ftp uploaded file is complete?
I need to create an upload progress monitor page that can discriminate between files that are partially uploaded and those that are completely uploaded. My users are uploading via FTP to an anonymous upload directory. I'm running mod_perl on the same machine, and it has access to just about anything on the machine that I care to give it access to. Does anyone have any suggestions on how I can discover from within my handler whether an FTP file upload is complete or not? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Matthew Kennedy wrote: from CPAN, then good for you. I'm sure you can in some cases. I think mod_perl has done an excellent job of conquering the the two-teir web-based problems. I love tools such as Mason and Apache::ASP which ride on mod_perl. Perl-DBI is an excellent advancement for Perl in general also. I think it's exciting to think what an n-tier framework in Perl might look like. IMHO, it should be more than just the outgrowth of CPAN's contents. i can't add anything to your statement other than emphatic "me too!" i'm glad to hear that others recognize that we have work to do and are excited about the possibilities. i wonder if there's enough excitement to think about producing some useful software! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validating Parsers
On Wed, Dec 06, 2000 at 10:57:44AM -0800, [EMAIL PROTECTED] wrote: hello Does anyone know of a xml parsing module that validates using built-in functionality, or is there a method to validate xml using XML::Parser with another module? XML::Checker::Parser? - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
On Wed, 6 Dec 2000, Aaron E. Ross wrote: while the install and auto configure part is not very glamorous, the possibility of being able to untar one package to get mod_perl w/ persistent db connections, transaction management, data relational modeling/objects and a nice templating/servlet engine is very glamorous! you could be a folk hero! honestly it seems like a pretty worthwhile project to me. basically, what is missing is (cough! cough!) simply a lot of hard work. except for transaction management, which is apparently of questionable value, all the pieces exist, right? database abstraction and connection pooling = DBI session management= Apache::Session load balancing= mod_backhand?? data relational mapping = Tangram or Alzabo templates or whatever you want to call them = HTML::Embperl/Mason/TemplateToolkit ide = pick an editor with a few hooks to call make, install and restart granted this may not get us everything, but if we could package up the stuff we all use over and over again, wouldn't that get us pretty far? Aaron I'm willing to contribute time to this project if given some input on how to proceed. perhaps take a look at AO - it's a good start at a servlet engine that packages at least a few of the items you've highlighted. i'd love to participate in a project that uses AO, backhand, an o/r mapping tool, and other components to provide an out of the box 2-tier system. i'd also love to see an "enterprise" or 3-tier version of same. let's organize! i suppose i should get the AO sourceforge site up and running eh? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: shared mem [was: mod_perl advocacy project resurrection]
On 12/6/00 3:42 PM, Paul wrote: The parent process could declare a shared memory segment at boot time. Each child's init could spawn a shared memory interface object. Wouldn't that allow for some resource pooling to be cleaner? How would that interact with per-child namespaces (if at all)? IPC::SharedCache and friends make this pretty simple. -John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Aaron E Ross writes: aer the possibility of being able to untar one package to get aer mod_perl w/ persistent db connections, [c.] is very glamorous! agreed. but fundamentally impossible. what database are you going to provide persistent connections to? mysql? not on my solaris box you're not, unless you're going to include mysql in your distribution. besides, i want sybase. ok, so skip the database and use DBM files, gdbm's everywhere, right? again, not (standard, anyway) on solaris. so, package up gdbm too. you can see where that's going. i think providing a mod_perl framework in which applications can be written is a noble idea. i think recommending a particular solution is great -- lots of people who hack mod_perl day in and day out can't keep up with all the new modules/products, a summary of what's available would be useful to new programmers and veterans alike. i also think that this is a case of walking before running: putting together a summary document of mod_perl development environments (mason, axkit, ao, c.) has (to the best of my knowledge) eluded us so far, the notion that we could bundle some together and get them to work is pie in the sky thinking. whoever said that packaging all this stuff together (i think it was MS or BM) is extremely difficult is absolutely correct. in my current shop, we have enough trouble creating packages that work on both solaris 6 and 8 without any modification, and we're pretty good at this sort of thing. bundling *just* mod_perl and apache in one package that can be build and installed by pushing a button seems like an excellent short term goal. for some people just starting out, you'd be a folk hero if you provided just this. (i'm not down on the idea really, but if packaging is going to be considered as a form of advocacy, it'd be nice if we attacked it in easy to digest chunks. starting with the two packages, and perhaps a couple sample applications and moving on from there.) aer except for transaction management, which is apparently of aer questionable value, i don't think anyone is claiming that transaction management is of questionable value -- when you need it, you need it; there's no substitute. (unless you consider reconciling databases by hand a substitute.) cheers, k. -- kevin montuori support independent booksellers -- http://www.booksense.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Apache::ASP v2.07
Hey,
The latest Apache::ASP 2.07 has made its way into CPAN, and is
also available at:
http://download.sourceforge.net/mirrors/CPAN/modules/by-module/Apache/
ftp://ftp.duke.edu/pub/perl/modules/by-module/Apache/
The Apache::ASP web site is at http://www.apache-asp.org/
This release solves some import $Session manager race conditions,
increases ASP PerlScript compatibility with the CollectionItem
feature, and has general performance enhancements. Upgrade to
this version while your site is idle, see CHANGES below for details.
Apache::ASP provides an Active Server Pages port to the Apache Web Server
with Perl scripting only, and enables the development of dynamic web
applications with session management and embedded perl code. There are
also many powerful extensions, including XML taglibs, XSLT rendering, and
new events not originally part of the ASP API!
The CHANGES for this release are below.
-- Josh
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
+ = improvement; - = bug fix
-+-+ Session Manager
empty state group directories are not removed, thus alleviating
one potential race condition. This impacted performance
on idle sites severely as there were now 256 directories
to check, so made many performance enhancements to the
session manager. The session manager is built to handle
up to 20,000 client sessions over a 20 minute period. It
will slow the system down as it approaches this capacity.
One such enhancement was session-ids now being 11 bytes long
so that its .lock file is only 16 characters in length.
Supposedly some file systems lookup files 16 characters or
less in a fast hashed lookup. This new session-id has
4.4 x 10^12 possible values. I try to keep this space as
large as possible to prevent a brute force attack.
Another enhancement was to limit the group directories
to 64 by only allowing the session-id prefix to be [0-3][0-f]
instead of [0-f][0-f], checking 64 empty directories on an
idle site takes little time for the session manager, compared
to 256 which felt significant from the client end, especially
on Win32 where requests are serialized.
If upgrading to this version, you would do well to delete
empty StateDir group directories while your site is idle.
Upgrading during an idle time will have a similar effect,
as old Apache::ASP versions would delete empty directories.
-$Application-GetSession($session_id) now creates
an session object that only lasts until the next
invocation of $Application-GetSession(). This is
to avoid opening too many file handles at once,
where each session requires opening a lock file.
+added experimental support for Apache::Filter 1.013
filter_register call
+make test cases for $Response-Include() and
$Response-TrapInclude()
+Documented CollectionItem config.
+New $Request-QueryString('multiple args')-Count()
interface implemented for CollectionItem config.
Also $Request-QueryString('multiple args')-Item(1) method.
Note ASP collections start counting at 1.
--fixed race condition, where multiple processes might
try creating the same state directory at the same time, with
one winning, and one generating an error. Now, web process
will recheck for directory existence and error if
it doesn't.
-global.asa compilation will be cached correctly, not
sure when this broke. It was getting reloaded every request.
-StateAllWrite config, when set creates state files
with a+rw or 0666 permissions, and state directories
with a+rwx or 0777 permissions. This allows web servers
running as different users on the same machine to share a
common StateDir config. Also StateGroupWrite config
with perms 0770 and 0660 respectively.
-Apache::ASP-Loader() now won't follow links to
directories when searching for scripts to load.
+New RegisterIncludes config which is on by default only
when using Apache::ASP-Loader(), for compiling includes
when precompiling scripts.
+Apache::ASP::CompileInclude path optimized, which underlies
$Response-Include()
+$Request-QueryString-('foo')-Item() syntax enabled
with CollectionItem config setting. Default syntax
supported is $Request-QueryString('foo') which is
in compatible. Other syntax like $Request-{Form}{foo}
and $Request-Form-Item('foo') will work in either case.
+New fix suggested for missing Apache reference in
Apache::ASP handler startup for RedHat RPMs. Added
to error message.
--Backup flock() unlocking try for QNX will not corrupt the
normal flock() LOCK_UN usage, after trying to unlock a file
that doesn't exist. This bug was uncovered from the below
group deletion race condition that existed.
-Session garbage collection will not delete new group
RE: mod_perl advocacy project resurrection
It's also dog slow. Has too many requirements (why should I *have* to install their Python on win32 if I'm a perl developer? or vice versa) Not terribly useful (very little syntax highlighting, little tabbing support). And the fact that it assumes you have perl 5.6, and whines when you don't. Though there is no requiremenet for such. -Original Message- From: Robin Berjon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 06, 2000 4:41 PM To: brian moseley Cc: Matthew Kennedy; mod_perl list Subject: Re: mod_perl advocacy project resurrection At 12:39 06/12/2000 -0800, brian moseley wrote: ActiveState has built an Perl/Python IDE out of Mozilla: http://www.activestate.com/Products/Komodo/index.html too bad it's windows only :/ That's bound to change. I think AS will release it on all platforms where Moz/Perl/Python run when it's finished. The current release is very unstable anyway. -- robin b. All paid jobs absorb and degrade the mind. -- Aristotle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
ActiveState has built an Perl/Python IDE out of Mozilla: http://www.activestate.com/Products/Komodo/index.html too bad it's windows only :/ It says at: http://www.activestate.com/Products/Komodo/index.html that it is cross platform for Windows, Linux, and Unix. The beta they have available for downloading is win only, but I can't imagine them not supporting the other platforms once it's released since it's based on mozilla, which has made quite an effort to be truely cross platform. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT]Re: mod_perl advocacy project resurrection
Aristotle from the Ars Rhetorica on money: Money will not make you wise, but it will bring a wise man to your door. Robin Berjon wrote: At 12:39 06/12/2000 -0800, brian moseley wrote: ActiveState has built an Perl/Python IDE out of Mozilla: http://www.activestate.com/Products/Komodo/index.html too bad it's windows only :/ That's bound to change. I think AS will release it on all platforms where Moz/Perl/Python run when it's finished. The current release is very unstable anyway. -- robin b. All paid jobs absorb and degrade the mind. -- Aristotle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] 1%, two-phase commits, etc.
"Jeffrey W. Baker" wrote:
Machine A is controlling a transaction across Machine X and Machine Y. A
modifies a row in X and adds a row to Y. A commits X, which succeeds. A
commits Y, which fails.
A cannot guarantee a recovery on machine X because there might already be
other transactions in flight on that record in that database. A cannot
just try to put the record back the way it used to be, because now the
commit might fail on X. The data is inconsistent.
As a couple others have noted, two phase (prepare-commit) commits solve the above
problem. But two phase commits are not a panacea. They just move Jeffrey's
problem elsewhere. Suppose A (in a two phase commit implementation, the
transaction coordinator) prepares X and Y, but then dies just after committing X,
but before committing Y. How does X know that Y hasn't committed, and that he
should roll back? He doesn't, unless we cons up some magic secondary
communication channel between X and Y.
One way to recover from the "A dies after telling X to commit" problem is to
shadow A with a mirror, A'. A' takes over for A, interrogates the servers to
find out who has committed the last transaction and who hasn't, and if necessary
completes the transaction or rolls it back (assuming all writes are serialized
through {A, A'}, so there hasn't been any intervening activity to confuse
things). Steady-state synchronization between A and A' is straightforward, as is
failure detection and recovery fall-over. In fact, if this is properly
implemented, the transaction processing system can keep going without a hitch
through any one failure, and the distributed dataset stays consistent.
Unfortunately, in many transaction middleware systems, you discover in the fine
print that A' is actually a semi-automated recovery process under the control of
a human administrator. Human? That would be Dork, down the hall, the Certified
Microsoft Solutions Fuckwad. Feel safe.
But let's go back to the example, and stipulate that a reasonable A' exists. Are
we now 100% consistent 100% of the time? No, in fact we're not. Because after X
commits and A dies, but before A' realizes that A has died and patches things up,
any reader of X and Y could potentially see an inconsistent view of the data. Do
we therefore serialize our reads through the transaction monitor, too? With a
distributed database, we have to, if we want a guaranteed-consistent view. Of
course, we could choose not to, for performance reasons.
Does all of this make your head spin just a bit? Hence Jeffrey's point. There's
a lot of margin for error, and the more that's buried in mysterious middleware,
the less confident you should be. If you can get away with a single server, you
dodge all these bullets.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Tue, Dec 05, 2000 at 09:32:41AM -0800, brian moseley wrote: On Tue, 5 Dec 2000, Stas Bekman wrote: But, you all know that php pretty much takes over. Why? For two reasons: 1) initial corporate pushing (press/ads) 2) once well known, the word of the mouth does the rest. oh, there's also the part about php being so much easier to setup and to program ;) if you really feel the need to compete with php in the lowest tier web app space, you need to make simplicity your #1 goal. php is awesome entry level technology, and i almost always recommend it over perl to people who only have the desire to do casual programming for personal sites and small projects. and that's a significant percentage of the people i know doing web programming. Actually, PHP's advantage is that you can install it and all 250 sites on that machine can use it without problems. You just can't do that sanely under mod_perl. snip we need to create standards for ourselves and fully embrace them. DBI is a great example. the explosion of mod_perl presentation technologies is a great counter example. But that's merely because we don't know what we want. Its only recently that people have decided that they wish to present data in XML and use XSL to display it. Prior to then the problem has been how to separate HTML from the code in such a way that the designers have an easy to use interface to the code. Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Take23
OK, so this isn't really much of an announcement, since its still the same web site. Anyway, I'm renaming modperl.sergeant.org to take23.org. DNS should propogate shortly. Until then its available at modperl.sergeant.org (and will continue to be available there). -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
"Matthew" == Matthew Kennedy [EMAIL PROTECTED] writes: Matthew I don't know where you got the 1GB disk requirement from? Matthew Even Weblogic's download is only 43Mb, jBoss' is about Matthew 6Mb. The Java Platform is somewhere between that. Your Matthew compiled enterprise app might only be 300Kb (and not just a Matthew "report queue manager"). And 500Mb of memory? That's Matthew tuppence in the server world anyway. This happens to be minimum numbers for working with a particular Application Server marketed by a well-known database vendor by the name of Oracle Corp. Matthew I think it's exciting to think what an n-tier framework in Matthew Perl might look like. IMHO, it should be more than just the Matthew outgrowth of CPAN's contents. I agree, but I should be able to expand and contract this middle tier monster in a very similiar fashion. Hey, I want some functionality, get it, configure it, install use it, derive from it, whatever. On the other hand, if I don't want, I can wipe it out without horking up the entire system. A degree of independence, sort of like the model driving a light weight operating system, where the base is a skeleton framework and I can plug in services, and uplug them, as necessary. I can create said services from existing ones via extension, or scratch together my own for a particular need. So CPAN has the concept just right. Matthew Sounds almost like you're talking about "enterprise" being Matthew a "company"? I know you can't be though... right? Yeah, right. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: be nice reminder [Was: mod_perl advocacy project resurrection]
But if we're talking advocacy, I must point out that as a newbie, my biggest problem was finding out where to look to *find* the manual. Also, when I was trying to get this system working ~now~, (the "out-of-the-box" problem we keep seeing), it was frequently important that I get answers quickly, and though I hated to bother the list with mundanities, it was a lot faster to ask (and get a response amid the RTFM's) than to read through a dozen documents to find where the information I needed, especially when it was ditributed among three or four of them and I needed to understand the relationships before it made any sense. We all find ourselves in the "I'm in a hurry" situation and before taking any time to look for an answer we sometimes blow our load and post a message. I've done that in the past and sometimes catch myself doing that on other lists (though I'm getting better :). The problem is that by time you post it, you've already spent considerable time describing your problem. Then there's the delay while it trickles out to the list and I usually spend my time searching the list archives. Roughly 80% of the time I will have found the answer within an hour of my post (and usually well before someone replies). What does this tell me? Regardless of how much of a rush we're in, it will still take some time before our question makes it to the list and by that time, if we use the resources made available to us, we'll have found the answer. Personally, I find the list archives to be *valuable* for most, if not all of the problems/questions I've had with mod_perl. I agree with Dave who said that if you are tackling new technology you should prepare to spend some time. No one I know who is trying out mod_perl is going to have it up and running with full-on-developed scripts in a day :-) Even with my 3 years experience using and configuring mod_perl it still takes me a good day to properly setup and configure out development and production boxes here. Jim -- Jim Serio - [EMAIL PROTECTED] Producer, World of Coasters - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: shared mem [was: mod_perl advocacy project resurrection]
--- "G.W. Haywood" [EMAIL PROTECTED] wrote: Hi Paul, On Wed, 6 Dec 2000, Paul wrote: Is there no Apache::SharedMemory (or some such)? If not, does anyone think it would be worth the time for someone (like me) to sit down and write it? (Couldn't it be done?) There be dragons. LOL!!! :O] I was pointed to IPC::Sharable, IPC::Sharelite. I'll look at those. __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: be nice reminder [Was: mod_perl advocacy project resurrection]
Agreed, one and all. I only meant to stress being polite when you ask people not to post off-topic without notice -- unless they *KEEP* doing it There are some who require rudeness, sadly enough. I just meant that if you're going to bother to respond, let the person know what they did wrong, try to point them in the right direction (with a sentence or two, not a soliloquay, =o) and ask them to put [OT] in if the next time they consider it important enough. If 50 polite "look here for answers to that, please" messages in response to a post don't make the point, then they *deserve* a little rudeness. A little. *after* having been given a clue. Remember, generic questions will politely punish the ask-er simply by the volume of polite response. =o) I didn't mean to sound like I was ranting! lol! --- Dave Rolsky [EMAIL PROTECTED] wrote: On Wed, 6 Dec 2000, Paul wrote: But if we're talking advocacy, I must point out that as a newbie, my biggest problem was finding out where to look to *find* the manual. Also, when I was trying to get this system working ~now~, (the "out-of-the-box" problem we keep seeing), it was frequently important that I get answers quickly, and though I hated to bother the list with mundanities, it was a lot faster to ask (and get a response amid the RTFM's) than to read through a dozen documents to find where the information I needed, especially when it was ditributed among three or four of them and I needed to understand the relationships before it made any sense. Well, your pressing schedule is your problem. If you're going to tackle a new technology you have to allow learning time. I'm all for people politely providing pointers as to what documentation a newbie should read (like "go to the guide from perl.apache.org and read the section on configuring"). But expecting people to then sit down and walk you through the commands necessary to get the install done is just not going to happen. If you need that sort of support, pay someone to do it for you. I highly doubt that this is any different in the Java world. Certainly, better packaging/smarter installers can help with this too. and friendly attitude towards (yes, even stupid) questions, I remind us all that one "RTFM and quit wasting our time, jerk" response will sour someone on the ENTIRE language, and that the someone might always have been the next Bill Gates looking for a tool to sponsor There's nothing wrong with RTFM and a pointers towards the correct books/sites/files, as long as its polite. Explaining how to access an entry in a hash isn't worth a lot of people's time -- but I see those people occasionally spend the time to point that out. While we're at it, let's always take the extra few seconds to be *nice* about it, and at least make a token effort while we mention that there's a better forum for that at [EMAIL PROTECTED] I think answering entirely off-topic questions instead of just politely asking the questioner to go elsewhere sets a bad precendent along the lines of "those mod_perl folks know Perl really well so I'll ask my regex question there." Keep in mind that while we're all for advocacy of mod_perl, eventually a person's support needs may reach a point where they really need to start thinking about paying for it. -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: shared mem [was: mod_perl advocacy project resurrection]
On Wed, 6 Dec 2000, Paul wrote: I was pointed to IPC::Sharable, IPC::Sharelite. I'll look at those. Take a look at IPC::MM for a shared memory hash implemented in C. Also, File::Cache is sometimes faster than the IPC modules. I don't think any of these solve problems like sharing sockets and file handles though. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl advocacy project resurrection
On Wed, 6 Dec 2000, Ben Thompson wrote: On Tue, Dec 05, 2000 at 09:32:41AM -0800, brian moseley wrote: if you really feel the need to compete with php in the lowest tier web app space, you need to make simplicity your #1 goal. php is awesome entry level technology, and i almost always recommend it over perl to people who only have the desire to do casual programming for personal sites and small projects. and that's a significant percentage of the people i know doing web programming. Actually, PHP's advantage is that you can install it and all 250 sites on that machine can use it without problems. You just can't do that sanely under mod_perl. Being in the webhosting industry, and running modperl-space.com, I'd suggest that this really is an issue... even for the hobbyist discussed earlier it's non-trivial to get a semi-serious mod-perl site online... the gap between running it off your cable modem at home and a dedicated server at a co-location facility is pretty big... our standard PHP configuration is CGI based, which gives us all the suexec benefits, and process count/size/cpu limiting by userid etc... for folks that go beyond php-cgi, we can go to mod_php, but it's rare... with mod_perl, there is no half step unless you want to call it perl-CGI ... and even then we all know the troubles of taking CGI/run-once PERL into a persistant environment... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
source filters in httpd.conf
Hi, I've been trying to use Perl source filters in httpd.conf but to no avail. The archives contain some information on using source filters in modules or registry scripts, but I couldn't find anything about using a filter with either use MyFilter in a Perl section or PerlModule MyFilter. I'm running 1.3.14 with 1.24_02 and I've built with EVERYTHING=1. The following Perl script works perfectly well: use MyConf::TestMe; use Apache::FilterConf; PerlFilterConfSetup MyConf::TestMe TestMe line PerlFilterConfSetup MyConf::TestMe TestMeToo block TestMe as a line TestMeToo as a block with some content /TestMeToo However all variations that I've tried in httpd.conf fail, even if I put it all inside a Perl section. What I'm trying to achieve is to make the creation of custom configuration directives easier, more flexible, and full Perl (no XS). In the above Perl snippet everything after "use Apache::FilterConf;" is filtered by a Perl routine. The PerlFilterConfSetup directives tell Apache::FilterConf to register with itself two directives called TestMe and TestMeToo that are defined in MyConf::TestMe (that is they have callbacks there). The other lines are parsed and appropriate callbacks called when the filter finds defined directives. If it sees a line with a directive that it doesn't know it simply passes it on using Apache-httpd_conf. Apache never sees the defined directives (which might lose you some info in mod_info, but that's a small price) and the callbacks are free to do what they want, parse the directives whichever way pleases them (they always get the raw text), add some stuff to the httpd.conf that Apache would see, die on errors, etc... Not all this is done cleanly yet (I'd like to be sure it's possible before I polish it) but it would all be possible if I could get filters to work in httpd.conf. Such a module would be imho very nice to have :) I guess that there is something in modperl interfering with filters that prevents the stream from going through the source filter (the filter() sub never gets called) but I don't know enough about modperl's internal to see what it is and to provide a patch (given that it's possible). So if anyone can provide me with a solution to make it work I'd be very happy to hear about it. Thanks, -- robin b. As a computer, I find your faith in technology amusing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
what about emacs? It has syntax high lighting/coloring/indenting, easy use of version control, the ability to do compile goto error line(fix) then debug, menu's that work under gui or tty and a bunch of features that I have not even learned yet. The version control is what sold me it is trival to use it and that sold me. marc - Original Message - From: brian moseley [EMAIL PROTECTED] To: Matthew Kennedy [EMAIL PROTECTED] Cc: mod_perl list [EMAIL PROTECTED] Sent: Wednesday, 6. December 2000 15:39 Subject: Re: mod_perl advocacy project resurrection On Wed, 6 Dec 2000, Matthew Kennedy wrote: ActiveState has built an Perl/Python IDE out of Mozilla: http://www.activestate.com/Products/Komodo/index.html too bad it's windows only :/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
the only thing I would add is DBI and DBD:::CSV, you get a basic prototyping db and you can add other drivers as you need them. And the package needs to specify the version of gcc it was built with, so you can add dso's and/or perl XS modules. I am more a sys admin then a programmer but I would be willing to build a Solaris package for this. IFF I find the time I would also look into doing it for FreeBSD and possibility OpenBSD, they both use the same packaging standard. I will not have time to start this for about 2 weeks though. Please keep in mind that I have no experience with mod_perl so I would need some noble soul to test the krap out of it. marc spitzer - Original Message - From: kevin montuori [EMAIL PROTECTED] To: Aaron E. Ross [EMAIL PROTECTED] Cc: Dave Rolsky [EMAIL PROTECTED]; brian moseley [EMAIL PROTECTED]; mod_perl list [EMAIL PROTECTED] Sent: Wednesday, 6. December 2000 17:17 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) Aaron E Ross writes: aer the possibility of being able to untar one package to get aer mod_perl w/ persistent db connections, [c.] is very glamorous! agreed. but fundamentally impossible. what database are you going to provide persistent connections to? mysql? not on my solaris box you're not, unless you're going to include mysql in your distribution. besides, i want sybase. ok, so skip the database and use DBM files, gdbm's everywhere, right? again, not (standard, anyway) on solaris. so, package up gdbm too. you can see where that's going. i think providing a mod_perl framework in which applications can be written is a noble idea. i think recommending a particular solution is great -- lots of people who hack mod_perl day in and day out can't keep up with all the new modules/products, a summary of what's available would be useful to new programmers and veterans alike. i also think that this is a case of walking before running: putting together a summary document of mod_perl development environments (mason, axkit, ao, c.) has (to the best of my knowledge) eluded us so far, the notion that we could bundle some together and get them to work is pie in the sky thinking. whoever said that packaging all this stuff together (i think it was MS or BM) is extremely difficult is absolutely correct. in my current shop, we have enough trouble creating packages that work on both solaris 6 and 8 without any modification, and we're pretty good at this sort of thing. bundling *just* mod_perl and apache in one package that can be build and installed by pushing a button seems like an excellent short term goal. for some people just starting out, you'd be a folk hero if you provided just this. (i'm not down on the idea really, but if packaging is going to be considered as a form of advocacy, it'd be nice if we attacked it in easy to digest chunks. starting with the two packages, and perhaps a couple sample applications and moving on from there.) aer except for transaction management, which is apparently of aer questionable value, i don't think anyone is claiming that transaction management is of questionable value -- when you need it, you need it; there's no substitute. (unless you consider reconciling databases by hand a substitute.) cheers, k. -- kevin montuori support independent booksellers -- http://www.booksense.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
how to setup the EMBPERL_MAILTOFROM?
I'm working on a e-mail form, and would like to use the MailToFrom EmbPerl module to do it. Can someone tell me what to add in the httpd.conf and please provide me with some code snippets on how to integrate this thing into the form. Thanks. Cheers, Kok Wei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: shared mem [was: mod_perl advocacy project resurrection]
Perrin Harkins wrote: On Wed, 6 Dec 2000, Paul wrote: I was pointed to IPC::Sharable, IPC::Sharelite. I'll look at those. Take a look at IPC::MM for a shared memory hash implemented in C. Also, File::Cache is sometimes faster than the IPC modules. I don't think any of these solve problems like sharing sockets and file handles though. Is there _any_ solution to sharing sockets? My WebMail server keeps a pool of IMAP connections open (one per user) but it currently needs to create a connection for every user for every process that they use. This is awfully inefficient. I'm planning on creating a little Unix Socket daemon that keeps a single pool of connections, and make all IMAP connections go through the daemon. This seems like it should be unnecessary though--isn't there some way of sharing sockets amongst processes? PS: I second your suggestion to look at File::Cache--I use it for my session store and find it excellent. Speed depends on your OS's bufferring, however. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
