This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: Ged Haywood <ged@jubileegroup.co.uk>, modperl@apache.org From: mkennedy@hssinc.com (Matthew Kennedy) Subject: Re: mod_perl advocacy project resurrection Date: Wed, 06 Dec 2000 15:33:47 -0600 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: brian moseley <bcm@maz.org> From: Robin Berjon <robin@knowscape.com> Subject: Re: mod_perl advocacy project resurrection Date: Wed, 06 Dec 2000 22:40:51 +0100 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. === To: brian moseley <bcm@maz.org> From: Ben Thompson <ben@babyhippo.com> Subject: Re: RFC: mod_perl advocacy project resurrection Date: Wed, 6 Dec 2000 21:34:14 +0000 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: mod_perl list <modperl@apache.org> From: Tom Brown <tbrown@baremetal.com> Subject: Re: RFC: mod_perl advocacy project resurrection Date: Wed, 6 Dec 2000 16:46:33 -0800 (PST) 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: "mod_perl list" <modperl@apache.org> From: "Marc Spitzer" <mspitze1@optonline.net> Subject: Re: mod_perl advocacy project resurrection Date: Thu, 7 Dec 2000 00:00:06 -0500 brian moseley <bcm@maz.org> wrote: > 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 :/ 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. === To: Jim Winstead <jimw@trainedmonkey.com> From: Tim Sweetman <tim@aldigital.co.uk> Subject: Re: RFC: mod_perl advocacy project resurrection Date: Thu, 07 Dec 2000 09:38:47 +0000 Jim Winstead wrote: > (of course, this only addresses scaling to a breadth of users, not > scaling into the enterprise area. that just requires real marketing > and hype.) I saw an article in the Financial Times the other day. Some people have written a "Fax your MP[1]" gateway (http://www.faxyourmp.org/). A quick GET tells us that their server is running php, though I seem to recall (reading about what they did previously) that they did some initial database crunching in Perl. :) The FT wondered why these handful of guys could put this thing together so quickly, when big institutional IT schemes seem to take forever to go nowhere at great cost (paraphrasing slightly). [1] That's "member of parliament", politician representing your area === To: "Keith G. Murphy" <keithmur@mindspring.com> From: Stas Bekman <stas@stason.org> Subject: Re: mod_perl advocacy project resurrection Date: Fri, 8 Dec 2000 19:06:55 +0100 (CET) On Fri, 8 Dec 2000, Keith G. Murphy wrote: > Stas Bekman wrote: > > > > Let me stright things out a bit, so you won't get misleaded by my post as > > a marketing call. > > > > What we want is very simple. > > > > 1. We want many users, so they will thoroughly test the software and spot > > bugs asap, so we -- current users will get a better product. > > > > 2. We want more developers, so they will write core mod_perl and 3rd party > > modules, again for us current users to re-use and save development > > time. > [cut] > > It strikes me that there might be a route not yet taken to increase > *availability* of mod_perl. > > Think about all the ISPs that host personal and small business web > sites. How many of them run Apache and allow their customers to code > Perl scripts? This route is partially taken. I've addressed these issue in one of the previous articles http://apachetoday.com/news_story.php3?ltsn=2000-11-27-001-01-OS-LF-PL And if you have an ISP that you want to become aware of mod_perl (and learn about problems and solution) please point them to this article. > Earthlink (which is huge), for one. Yet it doesn't have mod_perl > installed. But if it did, both Earthlink itself and the customers might > see performance benefits from Apache::Registry scripting. > > The two biggest obstacles I see to this: > > (1) Have to have a *reliable* way for customers to reload their Registry > scripts. Here's where some development work might be needed. > > (2) It might be argued that anything that *needs* Registry is too > heavy-duty for the ISP to want it running anyway. > > Thoughts? > > (I wonder if it might be possible to enlist the Apache folks to campaign > for this as well, since anything that keeps out the dread IIS is > desirable). What do you mean by enlisting the Apache folks? When is the demostration :) The real question is for someone to undertake the Safe module and make it working for mod_perl. I think we have discussed this before. I don't remember what was the conclusion. === To: Stas Bekman <stas@stason.org> From: Matt Sergeant <matt@sergeant.org> Subject: Re: mod_perl advocacy project resurrection Date: Fri, 8 Dec 2000 19:35:59 +0000 (GMT) On Fri, 8 Dec 2000, Stas Bekman wrote: > The real question is for someone to undertake the Safe module and make it > working for mod_perl. I think we have discussed this before. I don't > remember what was the conclusion. That its pretty hard to do, and requires Safe holes to be any use for anything serious. Although someone had DBI working through Safe that emailed me, but I've since discarded or lost that email. FWIW, I still have Apache::Safe hanging around here somewhere. Not that its any use though :-) === To: brian moseley <bcm@maz.org> From: Ask Bjoern Hansen <ask@valueclick.com> Subject: Re: mod_perl advocacy project resurrection Date: Fri, 8 Dec 2000 14:50:44 -0800 (PST) On Tue, 5 Dec 2000, brian moseley wrote: [...] > consider a scenario in which somebody uses a web interface > to signal an action, which is placed into a message queue. > on the other end of that queue, a service handles the event > with a transaction that spans multiple third tier systems. > > this is the kind of architecture that is begging to be > embraced by perl. Talarian have a Perl API for SmartSockets. I would think they have for their "SmartMQ" thingy too. If not then it's probably easy to make. http://www.talarian.com/products/smartsockets/ http://www.talarian.com/products/smartmq/ === To: mod_perl list <modperl@apache.org> From: Leon Brocard <acme@astray.com> Subject: Re: mod_perl advocacy project resurrection Date: Sat, 9 Dec 2000 12:00:20 +0000 Ask Bjoern Hansen sent the following bits through the ether: > Talarian have a Perl API for SmartSockets. I would think they have for > their "SmartMQ" thingy too. If not then it's probably easy to make. (rapidly going OT) There's a simple Perl interface to http://www.spread.org/ which works pretty well. === To: mod_perl list <modperl@apache.org> From: Gunther Birznieks <gunther@extropia.com> Subject: RE: mod_perl advocacy project resurrection Date: Sun, 10 Dec 2000 21:34:29 +0800 At 09:27 AM 12/6/00 +0000, Matt Sergeant wrote: >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. I think you are right for AxKit. I assume some modules you depend on are compiled (eg XML::Parser). If this is the case, then it's a pain in the ass to manage distributing all the modules together. And since you rely on mod_perl, you already assume a certain level of expertise that your users have. However, in our toolkit, we do ship CPAN modules with it. But this is only for modules that don't require compilation and because we want someone who downloads our apps to run it on any web server out there -- no dependencies. Yet, if there is mod_perl, the apps will run fast. So I think both models are appropriate. And I believe you are right to distribute AxKit the way you do. === To: woody@bga.com, Chris Winters <chris@cwinters.com> From: Gunther Birznieks <gunther@extropia.com> Subject: Re: mod_perl advocacy project resurrection Date: Sun, 10 Dec 2000 21:39:25 +0800 At 12:06 AM 12/6/00 -0600, Jim Woodgate wrote: >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... :) This is very similar to SpeedyCGI + mod_speedy. Although it's more like a servlet engine model than actually get access to Apache API. SpeedyCGI is not web server specific (except the mod_speedy module). >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... :) There have been public domain libraries to write to syslogd in Java for a long time. The only problem with Java in this regard is that there is no CPAN. But if you search on the net, you can usually find something in Java that has the equivalent to a CPAN module that deals with networking as Java makes networking quite easy. >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. I don't see why you are having a problem. We do it all the time for utilities we don't have any other access to. === To: mod_perl list <modperl@apache.org> From: Gunther Birznieks <gunther@extropia.com> Subject: Re: RFC: mod_perl advocacy project resurrection Date: Sun, 10 Dec 2000 21:45:42 +0800 At 08:26 PM 12/5/00 +0000, Matt Sergeant wrote: >On Tue, 5 Dec 2000, Eric Strovink wrote: > > > A number of people have been beating around this bush, so why not just > > mow it down? > > > > A huge win for advocacy would be a small set of complete example > > applications targetted at, say, the last two RedHat distros. Each > > application should install itself -- .conf files, .htaccess files, > > dbm's, directory structures, perl code, html and templates, correct > > version of Perl, CPAN packages for any stuff needed, Apache, mod_perl, > > mod_ssl, mod_whatever, mysql, database schemas, database contents, > > DBI, Session, front-end proxy -- everything. Each application should > > gronk whatever's already there, or rename it out of the way. > > Warnings in big letters. Tough doots. > >Do you have any idea how hard this is? Seriously. Because I do. Dave >Rolsky does. And doing this for free is going to be nigh on impossible. > > > Each application package should contain dumbed-down documentation that > > explains what it does, and how it does it. > >Good writers are really hard to come by. Good writing is also quite time consuming to do. Arguably even more so than coding when you take into account drawing diagrams and testing the writing/instructions. >I don't want to poo-poo on the idea by any means, the *idea* itself is >fine, but the implementation of it is non-trivial. I agree. Huge binary distribution might be nice (similar to the Win32 Apache Mod_Perl binary) but it is fraught with a lot of work. I think there are ways to make the Apache/mod_perl install easier which perhaps should be more the focus instead. Things I'd like to see: 1) mod_perl problems with DSO solved. DSO would make it easy to compile one apache and then install mod_perl as a separate RPM. 2) shell scripts that do some introspection on how Apache was compiled in the first place and creates a shell script to do the final compilation instead of having to guess all the cmdline params. #2 is not easy, but I think there are heuristics that could certainly help. At the very least a sample shell script to go along with each type of install with commented out params would help provide a simple example. Then the user could selectively delete the comments if they want that cmd line parameter. I find installing mod_perl when I haven't done it in months very annoying because I have to keep hunting around readme's to discover the cmdlines that I used. === To: Jay Jacobs <jay@lach.net>, Stas Bekman <stas@stason.org> From: Gunther Birznieks <gunther@extropia.com> Subject: RE: mod_perl advocacy project resurrection Date: Sun, 10 Dec 2000 22:07:22 +0800 At 01:05 PM 12/5/00 -0600, Jay Jacobs wrote: >On Tue, 5 Dec 2000, Stas Bekman wrote: > > > What we want is very simple. > > > > 1. We want many users, so they will thoroughly test the software and spot > > bugs asap, so we -- current users will get a better product. > > > > 2. We want more developers, so they will write core mod_perl and 3rd party > > modules, again for us current users to re-use and save development > > time. The first item is directly linked to the second, as new developers > > come out from users. > >I think a good first step in that direction is to have mod_perl modules to >do some of the basic things that early web developers want... a few really >well documented and tailored-for-newbies modules. I think back a few >years to "Matt's Script Archive", and what that did for perl and >CGI. (Anyone for Apache::Formmail?) > >Just some stuff to get the new developer interesting in figuring out how >to compile mod_perl, and to see the benefits of it. It could even be done >with step-by-step examples, with gradually increasing functions. ( "Now >move on to Guestbook-DBI" ... "Now add in Apache::Session for such-n-such >functions" ) Perhaps even offer the same modules under mason, embperl >axkit, etc. so folks can take a step in those directions too. I think this is what the Eagle book does really. But within your idea, I would advocate more standalone applpications. It so happens that the guestbook we distribute on eXtropia supports flatfiles on mod_perl but if you want, you can graduate it to a DBI version that works with mod_perl. >I just think back to the time when I started putting smarts-to-web and >these were the first steps I took, and I looked for that kind of hand >holding as I figured out how to make it work. I think this makes sense. I could also see Apache::FormMail being interesting if it was written from an ISP perspective (giving users a form mail that can be used by any server). BTW, our WebResponder app (Basically same as Matt Wright's Form Mail) works with mod_perl too. Same as our WebDB and our WebCalendar. === To: Stas Bekman <stas@stason.org>, Eric Strovink <strovink@acm.org> From: Gunther Birznieks <gunther@extropia.com> Subject: Re: RFC: mod_perl advocacy project resurrection Date: Sun, 10 Dec 2000 22:19:30 +0800 At 09:13 PM 12/5/00 +0100, you wrote: >On Tue, 5 Dec 2000, Eric Strovink wrote: > > > A number of people have been beating around this bush, so why not just > > mow it down? > > > > A huge win for advocacy would be a small set of complete example > > applications targetted at, say, the last two RedHat distros. Each > > application should install itself -- .conf files, .htaccess files, > > dbm's, directory structures, perl code, html and templates, correct > > version of Perl, CPAN packages for any stuff needed, Apache, mod_perl, > > mod_ssl, mod_whatever, mysql, database schemas, database contents, > > DBI, Session, front-end proxy -- everything. Each application should > > gronk whatever's already there, or rename it out of the way. > > Warnings in big letters. Tough doots. > > > > Each application package should contain dumbed-down documentation that > > explains what it does, and how it does it. > > > > The idea would be to put into people's hands several different > > complete, debugged, sophisticated frameworks for building the rest of > > their application. All the hard stuff's done -- .conf, proxying, DBI, > > session control, cookies, templating, compiling, building, and so on. > > All the newbie has to do is tweak an already-working example, without > > necessarily understanding all of what s/he's been given. > >Sounds like a good project fore Xtropia.com... Gunther? We already do this for CGI/flatfile distribution. I suppose we could experiment with making a mod_perl,mySQL optimized solution for our stuff. I have an intern who could probably make this work within the next couple of months. I don't think I would do more by making a binary mySQL/Apache/mod_perl distro along with our apps though. That's too much of a can of worms. === To: Gunther Birznieks <gunther@extropia.com> From: <spam@vancouver.yi.org> Subject: Re: mod_perl advocacy project resurrection Date: Sun, 10 Dec 2000 13:45:08 -0800 (PST) On Sun, 10 Dec 2000, Gunther Birznieks wrote: > >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. You can do the twostage server if you are short on memory, speed is important and usage of active content is relatively low. Setup a mod_proxy and stripped down apache for port 80 and mod_perl for port 8080 for example. Proxy certain urls to the 8080 and you are good. Set low number for the mod_perl items, to avoid thrashing. I'd see where Java is weak, integration wise like 2 MB per process and not even integrated string processing. > >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. Java movement has stretched out itself too thin, they did not identify themselves with a particular niche, and so we did it for them, where they don't really excell either - web applets, flash is more fit for that sort of thing. Perl is not very known for doing gui but spreading out knowlege about perl/tk helps. Which is just as good as AWT(? not sure of the name) > >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. So is with FastCGI, reinventing the wheel man is not a good thing. Sun people are on this thing to rewrite the world and put a Sun stamp on it and make everybody use it. Whahoo. > >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). Try FastCGI, it is really fast if you can do multiplexing. Besides the fact, I will write apache C modules if I need speed, not use some unproven languages to handle maximum loads, with lowest response time. > >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... :) > > This is very similar to SpeedyCGI + mod_speedy. Although it's more like a > servlet engine model than actually get access to Apache API. SpeedyCGI is > not web server specific (except the mod_speedy module). Good one. However would you really get the advantage of performing configuration manipulations on the fly? Or dynamic generation of the configs form templates and lists of values? > > >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... :) > > There have been public domain libraries to write to syslogd in Java for a > long time. The only problem with Java in this regard is that there is no > CPAN. But if you search on the net, you can usually find something in Java > that has the equivalent to a CPAN module that deals with networking as Java > makes networking quite easy. Sun was not onto community thing anyways, they're corporation, and giving up a control something they spend money on, will give chills to the managing types that are not for the OS thing. No CPAN is an oversight for the Java people, but really how can they implement it? Java runs across many platforms and VMs for it are written by many companies. If one dares to do something like that. For one they have to figure out how not to breach security of systems where people will be installing custom java classes. Java like windows2000 was touted for the security and CPAN like thing will bring some bugs and holes into the frame work I am almost sure. === To: <spam@vancouver.yi.org> From: Jim Woodgate <woody@realtime.net> Subject: Re: mod_perl advocacy project resurrection Date: Sun, 10 Dec 2000 15:37:02 -0600 (CST) spam@vancouver.yi.org writes: > You can do the twostage server if you are short on memory, speed is > important and usage of active content is relatively low. Setup a mod_proxy > and stripped down apache for port 80 and mod_perl for port 8080 for > example. Proxy certain urls to the 8080 and you are good. Set low number > for the mod_perl items, to avoid thrashing. I'd see where Java is weak, > integration wise like 2 MB per process and not even integrated string > processing. I'm sorry I wasn't more clear in my first response. My main point was not that the common threads I've seen on this mailing list didn't have good solutions. It was that these things come up alot, and although there are good solutions, they typically involve something beyond mod_perl... I've used dbm files and shared memory before, and I find it easier to use the built in thread support in java (like I said IMHO of course :) > So is with FastCGI, reinventing the wheel man is not a good thing. > Sun people are on this thing to rewrite the world and put a Sun stamp on > it and make everybody use it. Whahoo. Never looked at FastCGI, does it allow the request to query the server while it is running, or is it more like a call to an external server than get a response? Also, if there are multiple processes running I don't see how that is any better than mod_perl with a proxy for static pages? I would also agree that for things that require hooks into the apache api, mod_perl can do things that just can't be done with the other systems. I was simply playing devil's advocate in pointing out that common themes on this list are non-problems with some other solutions, and if we're talking advocacy, these issues might come up... === To: <woody@bga.com> From: Matt Sergeant <matt@sergeant.org> Subject: Re: mod_perl advocacy project resurrection Date: Mon, 11 Dec 2000 10:07:36 +0000 (GMT) On Sun, 10 Dec 2000, Jim Woodgate wrote: > > spam@vancouver.yi.org writes: > > You can do the twostage server if you are short on memory, speed is > > important and usage of active content is relatively low. Setup a mod_proxy > > and stripped down apache for port 80 and mod_perl for port 8080 for > > example. Proxy certain urls to the 8080 and you are good. Set low number > > for the mod_perl items, to avoid thrashing. I'd see where Java is weak, > > integration wise like 2 MB per process and not even integrated string > > processing. > > I'm sorry I wasn't more clear in my first response. My main point was > not that the common threads I've seen on this mailing list didn't have > good solutions. It was that these things come up alot, and although > there are good solutions, they typically involve something beyond > mod_perl... > > I've used dbm files and shared memory before, and I find it easier to > use the built in thread support in java (like I said IMHO of course :) Except that won't scale beyond 1 server... === To: Matt Sergeant <matt@sergeant.org>, <woody@bga.com> From: Gunther Birznieks <gunther@extropia.com> Subject: Re: mod_perl advocacy project resurrection Date: Mon, 11 Dec 2000 18:25:23 +0800 At 10:07 AM 12/11/2000 +0000, Matt Sergeant wrote: >On Sun, 10 Dec 2000, Jim Woodgate wrote: > > > > > spam@vancouver.yi.org writes: > > > You can do the twostage server if you are short on memory, speed is > > > important and usage of active content is relatively low. Setup a > mod_proxy > > > and stripped down apache for port 80 and mod_perl for port 8080 for > > > example. Proxy certain urls to the 8080 and you are good. Set low number > > > for the mod_perl items, to avoid thrashing. I'd see where Java is weak, > > > integration wise like 2 MB per process and not even integrated string > > > processing. > > > > I'm sorry I wasn't more clear in my first response. My main point was > > not that the common threads I've seen on this mailing list didn't have > > good solutions. It was that these things come up alot, and although > > there are good solutions, they typically involve something beyond > > mod_perl... > > > > I've used dbm files and shared memory before, and I find it easier to > > use the built in thread support in java (like I said IMHO of course :) > >Except that won't scale beyond 1 server... But that's the same thing with IPC shared mem modules yet people still use them on mod_perl for various tricks. It's still easier in Java to do that sort of sharing -- at least it is for me. As always, other people's mileage may vary. === To: Matt Sergeant <matt@sergeant.org> From: Jim Woodgate <woody@realtime.net> Subject: Re: mod_perl advocacy project resurrection Date: Mon, 11 Dec 2000 11:25:58 -0600 (CST) Matt Sergeant writes: > > Except that won't scale beyond 1 server... If I needed to go beyond one server in java, I would probably look at something like Objectspace Voyager, which is the easiest to use orb I've ever seen. Is there anything similar in perl? I'd love to try it out! === To: <woody@bga.com> From: Matt Sergeant <matt@sergeant.org> Subject: ORBs Date: Mon, 11 Dec 2000 17:30:54 +0000 (GMT) On Mon, 11 Dec 2000, Jim Woodgate wrote: > > Matt Sergeant writes: > > > > Except that won't scale beyond 1 server... > > If I needed to go beyond one server in java, I would probably look at > something like Objectspace Voyager, which is the easiest to use orb > I've ever seen. Is there anything similar in perl? I'd love to try it > out! CORBA::ORBit is very simple to use. I'd be very interested in hearing from anyone who has used this in a mod_perl project. ===