Re: mod_perl advocacy project resurrection
At 01:45 PM 12/10/00 -0800, [EMAIL PROTECTED] wrote: On Sun, 10 Dec 2000, Gunther Birznieks wrote: [much stuff snipped] 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. Well, with Java, because the modules are not compiled, you don't really need CPAN in the sense of a perl Makefile.pl style. I was really referring to a central repository of code period. There are Java "directories" but nothing like CPAN. I am disappointed at things like gamelan because whenever I want to find something (Ill pick on Gamelan specifically here) (A) Gamelan is slow (B) It's really hard to search on package categories (C) The code points to someone else's website... so it's at the whim of the author still being around. Worse, 75% of the links seem to lead to commercial or shareware sites that gladly take your money if you want to use the class library. I don't think that a CPAN for Java is a security issue any more so than CPAN. It just would be nice to at least have a searchable directory of open source Java libraries. As for SUN not wanting a CPAN, I dont think thats true. They would love to see people writing more open source on top of Java. That doesn't mean that Java itself would be distributed there, but certainly non JDK originated stuff could go into a central directory. Later, Gunther
Re: mod_perl advocacy project resurrection
On Sun, 10 Dec 2000, Jim Woodgate wrote: [EMAIL PROTECTED] 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... -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: mod_perl advocacy project resurrection
At 10:07 AM 12/11/2000 +, Matt Sergeant wrote: On Sun, 10 Dec 2000, Jim Woodgate wrote: [EMAIL PROTECTED] 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.
Re: mod_perl advocacy project resurrection
On Mon, 11 Dec 2000, Gunther Birznieks wrote: 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. I don't disagree with you. I wish it were easier in Perl too. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: mod_perl advocacy project resurrection
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! -- [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
At 09:27 AM 12/6/00 +, 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. Later, Gunther - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
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. Later, Gunther - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
I don't mean to naysay it, but this is going to start getting quite binary specific. I guess you could maintain an RPM for Linux, but beyond that it seems quite difficult. And even if you maintain it as an RPM for Linux, do you make your own Perl distro with it or use RedHat's crappy distro? Or? On Linux I think installing Apache with Mod_Perl is almost trivial. What might be needed is some shell scripts that automate the process to accompany the readme's. It's the other platforms that are a bear for me personally. But if you made a binary for every platform. Wah! So hard. I think you are better off not touching the binary stuff and sticking to writing a traditional app framework that is not dependent on mod_perl, is not dependent on any database, but can make use of such things. Then, people can upgrade as they see fit. Later, Gunther At 03:54 PM 12/6/00 -0500, Aaron E. Ross wrote: 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] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
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. Later, Gunther - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
At 02:01 PM 12/6/00 -0800, brian moseley wrote: 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 be fair with regards to application toolkits, there's also SmartWorker.org and our eXtropia stuff. :) We already have 3-tier solutions working on our apps using SOAP as the primary marshalling protocol acting as a proxy to Java versions of our objects. This allows us to do intelligent database and rowset result caching on a multithreaded Java server while the front-end Perl apps just marshall calls in to that server using SOAP. I do wish there were more app toolkits out there as it would create more choice and provide some good experiments about what's a good mechanism for developing apps. eg I found looking at SmartWorker very interesting to see what I liked and did not like and Microsoft ASP for what I liked and didn't like. Of course, I disliked most of Microsoft ASP, but I did like ADO, so we stole the concept and implemented it in Perl and Java (JDO is still not out yet officially from JavaSoft). Of course, app toolkits are tough to write, and then you have to write or find people to write real apps on top of them to validate the design work. Later, Gunther - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
[EMAIL PROTECTED] 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... -- [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
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. happy hacking, pavel
Re: mod_perl advocacy project resurrection
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. Leon -- Leon Brocard.http://www.astray.com/ yapc::Europehttp://yapc.org/Europe/ ... All new improved Brocard, now with Template Toolkit! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Matthew Kennedy writes: If I were developing an application which fit well into the two-tier model however, a mod_perl based plan would be my first preference -- development time is shorter than JSP/Servlet and maintainability is _at_least_ comparible. I would add that the "java is easier to maintain" issue is IMHO the biggest myth of java. I've seen a bunch of over-engineered java the past couple of years and when something goes wrong, be afraid! :) -- [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
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. _ 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://logilune.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 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 :-) -- 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
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? 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). - 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: [...] 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/ - 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: Smart installing (Re: mod_perl advocacy project resurrection)
At 07:12 AM 12/7/00 -0500, barries wrote: On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: the only thing I would add is DBI and DBD:::CSV, No joins. Therefore not very useful. Actually joins are over-rated for most simple apps. It's very easy to make a calendar, address book and other common apps w/o joins. With that said though, DBD::CSV has some serious short-comings. Not the least of which is the lack of file locking. But because of the popularity of flatfile databases for newbies, that's why in our application toolkit we ended up making an abstraction that sits about more than just DBI -- native flatfiles, XML files, LDAP, SOAP, etc.. called DataSource with its own query language roughly similar in concept to Microsoft's ADO. Love it or hate it (most people who have used it do love it or hate it). 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. If you're doing that, you've graduated yourself to recompiling the whole kit and kabootle. That's probably true. One thing that would make things much easier for mod_perl is to get the DSO mechanism fully working. A lot of ISPs compile apache with DSO support, and so making mod_perl work well with DSO would help so that you don't have to ship a pre-compiled apache. Anyway, I think people need binary distributions really. Make is too complicated for a lot of newbies. - 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, kevin montuori wrote: 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. Well, I see the problem, but ... when you install J2EE or WebSphere, you don't actually get DB2 or Oracle installed too. You do however, get an interface to a connection pooling mechanism, all you have to do is code it ( and maybe configure it ). I'm imagining the same thing. If you need a feature, turn it on. No CPAN, Compilation, etc ... Rather than having to install Apache::Session,DBI,DBD each time, it should be ready to go with whatever database you are using.. or not at all. Providing compiled version of DBD drivers is harder, but not necessarily in the scope of this project. Oracle provides their own jdbc drivers, not Sun and yet it is still a easier install. I agree that providing a complete working, just add water environment is impossible, but providing the groundwork for one is not. So let's start, as you suggested, with two goals 1) bundling working versions of apache and mod_perl 2) providing summaries and descriptions of mod_perl development environments. Aaron - 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" wrote: 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 I'd say that load balancing is too involved an issue to make it into a package, I'd leave it aside, as anyone actually needing it will be certainly building his apaches manually. And I would also leave the IDE aside, (although I think I have a great candidate[1]). IDEs are very personal things, and users are sometimes very attached to theirs ... so much that merely installing an IDE is sometimes an offence. [1] Having grown up in a cushioned, fancy VB 3.0 IDE, I still find both vi, emacs and textmode debug too harsh for me. So I've been toying with the early releases of Komodo (http://www.ActiveState.com/Products/Komodo.html) and I actually like it although its far from finished. Has anyone used/tested it? martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT]Re: mod_perl advocacy project resurrection
At 14:47 06/12/2000 -0800, ed phillips wrote: Aristotle from the Ars Rhetorica on money: Money will not make you wise, but it will bring a wise man to your door. :) -- robin b. Forty two. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Matt, Everything required to make the module work ought to be included in the package or at least cross referenced to it. I have been having a problem in which I have had to manually resolve module dependencies on a Solaris 2.6 box. It went through several layers with several candidates for each layer. It's taken me a couple of months to get here. If you want corporate america to buy in to Perl, which seems to be the general gist of this thread, and not to loose any of the freedom you have in coding Perl, then you are going to have to find a way to make Perl easier to use. If it stays this hard, most employers are not going to let their precious IT staff devote time and energy to doing things in Perl that they can buy off the shelf elsewhere. It's really been an ugly process. My suggestion, I think that CPAN could make things a whole lot easier by simply asking the folks who wrote the module to link to the things it's dependent on. I also think that CPAN could make a good many folks lives easier by listing system requirements, when known. My point is that if things have been this bad for me, an end user (Joe Small Business Owner) would have given long ago and used php for his web site because he can probably figure that out. 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. -- 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] -- Jimi Thompson Web Master L3 communications "It's the same thing we do every night, Pinky." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Thu, 7 Dec 2000, Jimi Thompson wrote: Matt, Everything required to make the module work ought to be included in the package or at least cross referenced to it. I have been having a problem in which I have had to manually resolve module dependencies on a Solaris 2.6 box. It went through several layers with several candidates for each layer. It's taken me a couple of months to get here. If you want corporate america to buy in to Perl, which seems to be the general gist of this thread, and not to loose any of the freedom you have in coding Perl, then you are going to have to find a way to make Perl easier to use. If it stays this hard, most employers are not going to let their precious IT staff devote time and energy to doing things in Perl that they can buy off the shelf elsewhere. It's really been an ugly process. My suggestion, I think that CPAN could make things a whole lot easier by simply asking the folks who wrote the module to link to the things it's dependent on. I also think that CPAN could make a good many folks lives easier by listing system requirements, when known. My point is that if things have been this bad for me, an end user (Joe Small Business Owner) would have given long ago and used php for his web site because he can probably figure that out. I'm starting to come around to this now, especially with AxKit which relies on so many modules. I used to be a big fan of Activestate's PPM system (still am, only I don't use NT any more). I just wish it could work reliably on Linux, with so many different linux versions around. -- 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
"Bruce W. Hoylman" wrote: "Matthew" == Matthew Kennedy [EMAIL PROTECTED] writes: snip 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. ;-) Could someone actually be using Oracle's Application Server! 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. I agree with this. A pluggable architecture is nice. Incidentally, that's what the J2EE platform offers as well. For instance; I don't have to use JavaMail with EJB, or the Java Messaging System with EJB, or even JDBC with EJB either etc. Those modules would not necessarily have to be loaded into a JVM in order for me to use the rest of the framework. Sounds to me that this would not be too hard to do in a Perl context either. I think in general the work gone into J2EE's specification and rationale might be an excellent requirements model for a Perl n-tier equivalent. snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
I don't know about that, getting the correct version of perl, mod_perl. apache and all the preconfigured modules together and configuring cpan... as apposed to installing DBD::Postgres(uses XS), hell I could stick gcc postgres and open ldap in the package. krap I just gave my self more work. Here is the list so far: apache postgres openldap perl mod_perl libnet configure CPAN DBI DBD::CSV DBD:Pg BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs glibc, I think berkelyDB perl module GCC gmake This gives you a nice base system and everything you need to add stuff to it. Now I have 2 questions for the list: 1: is this a good idea or a waste of my time 2: did I forget anything marc - Original Message - From: barries [EMAIL PROTECTED] To: Marc Spitzer [EMAIL PROTECTED] Cc: mod_perl list [EMAIL PROTECTED]; Marc Spitzer [EMAIL PROTECTED] Sent: Thursday, 7. December 2000 7:12 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: the only thing I would add is DBI and DBD:::CSV, No joins. Therefore not very useful. 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. If you're doing that, you've graduated yourself to recompiling the whole kit and kabootle. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Marc, In order to be kind to newbie's, you will need to mention tar and gnu zip which don't come standard on some flavors of Unix. In my case Solaris 2.6 only has tar. Zip must be installed. Also, you are going to need to at least point them to documentation. Maybe we could make extra $$$ selling tech support for your bundle (a la Red Hat)??? The extra cabbage could go to buying ads. I think the goal of the "total installation" should be something akin to M$ Office if you are aiming at the corporate/business user. PHB's like things that they feel like they can control. I have no idea how you could idiot proof this, though, unless you set LOTS of defaults. Marc Spitzer wrote: I don't know about that, getting the correct version of perl, mod_perl. apache and all the preconfigured modules together and configuring cpan... as apposed to installing DBD::Postgres(uses XS), hell I could stick gcc postgres and open ldap in the package. krap I just gave my self more work. Here is the list so far: apache postgres openldap perl mod_perl libnet configure CPAN DBI DBD::CSV DBD:Pg BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs glibc, I think berkelyDB perl module GCC gmake This gives you a nice base system and everything you need to add stuff to it. Now I have 2 questions for the list: 1: is this a good idea or a waste of my time 2: did I forget anything marc - Original Message - From: barries [EMAIL PROTECTED] To: Marc Spitzer [EMAIL PROTECTED] Cc: mod_perl list [EMAIL PROTECTED]; Marc Spitzer [EMAIL PROTECTED] Sent: Thursday, 7. December 2000 7:12 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: the only thing I would add is DBI and DBD:::CSV, No joins. Therefore not very useful. 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. If you're doing that, you've graduated yourself to recompiling the whole kit and kabootle. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jimi Thompson Web Master L3 communications "It's the same thing we do every night, Pinky." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smart installing (Re: mod_perl advocacy project resurrection)
Thanks for pointing that out, or I could just use compress. As far as the $$$ goes you need to spend money to start a business lets see if there is a market first. Another thing we could add is interbase to the list or break it up into 3 or more packages that are integrated out of the box, call it rev 2( with no rev 1 yet). here is what I see if I do that later: 1: apache/perl/modperl/dbi/dbd for all supported db and there client code/ldap client 2: open ldap/berkelydb 3: postgress 4: interbase 5: mysql ... more stuff here N: auxiliary package gcc/gmake and what ever else these components would all have to work out of the box with each other, I install 1 on my web server and 2 on my ldap box and it works or I install both on 1 box and it works. Everything should go under 1 directory /opt/something/(apache|ldap|postgress) etc. This will be a good deal of not fun work though. The way to idiot proof something is to not listen to idiots, this is where it goes and that is the end of it. Give people a list of where each default is web root, datafiles for interbase postgres openldap in a step by step pre install guide and have them start at step 1 and go to step N and you have installed the package(s) you need. marc - Original Message - From: Jimi Thompson [EMAIL PROTECTED] To: Marc Spitzer [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, 7. December 2000 13:40 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) Marc, In order to be kind to newbie's, you will need to mention tar and gnu zip which don't come standard on some flavors of Unix. In my case Solaris 2.6 only has tar. Zip must be installed. Also, you are going to need to at least point them to documentation. Maybe we could make extra $$$ selling tech support for your bundle (a la Red Hat)??? The extra cabbage could go to buying ads. I think the goal of the "total installation" should be something akin to M$ Office if you are aiming at the corporate/business user. PHB's like things that they feel like they can control. I have no idea how you could idiot proof this, though, unless you set LOTS of defaults. Marc Spitzer wrote: I don't know about that, getting the correct version of perl, mod_perl. apache and all the preconfigured modules together and configuring cpan... as apposed to installing DBD::Postgres(uses XS), hell I could stick gcc postgres and open ldap in the package. krap I just gave my self more work. Here is the list so far: apache postgres openldap perl mod_perl libnet configure CPAN DBI DBD::CSV DBD:Pg BerkleyDB 3.x (openLDAP), this could cause a problem 2.x in in some linuxs glibc, I think berkelyDB perl module GCC gmake This gives you a nice base system and everything you need to add stuff to it. Now I have 2 questions for the list: 1: is this a good idea or a waste of my time 2: did I forget anything marc - Original Message - From: barries [EMAIL PROTECTED] To: Marc Spitzer [EMAIL PROTECTED] Cc: mod_perl list [EMAIL PROTECTED]; Marc Spitzer [EMAIL PROTECTED] Sent: Thursday, 7. December 2000 7:12 Subject: Re: Smart installing (Re: mod_perl advocacy project resurrection) On Thu, Dec 07, 2000 at 12:30:53AM -0500, Marc Spitzer wrote: the only thing I would add is DBI and DBD:::CSV, No joins. Therefore not very useful. 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. If you're doing that, you've graduated yourself to recompiling the whole kit and kabootle. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jimi Thompson Web Master L3 communications "It's the same thing we do every night, Pinky." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
This has been a really interesting thread. I would like to contribute my own experiences as I am currently sitting on both sides of the fence. In my spare time, what little there is, I operate a web hosting service for NZ Christian churches, organisations and ministries. This endeavour also operates as a ministry and hence comes under some very real constraints, the biggest being a very low budget. I can not afford to run top-end servers so must make the best of fairly modest equipment. I can not afford to hire programmers, so I do all the system admin and programming myself. I opted for Perl as I was reasonably comfortable with it and wanted an environment where I could build what I needed quickly and it would be relatively easy to look after. In the early days, I used to pull my hair out trying to get each new release of apache and mod_perl running, the problem was usually compounded by adding SSL. The arrival of Ralph's mod_ssl and the more recent apache and mod_perl distributions have helped heaps. What do I do with mod_perl, at this time it serves 3 purposes 1. It allows me to use my PostgreSQL database for web authentication (AuthDBI), 2. It offers database connection persistence, 3. It operates as a CGI accelerator. I haven't needed to work directly with mod_perl but have some things I would like to use it for next year. But my own site is only one of 150 odd on the server and I am the only one using mod_perl, a couple of sites use PHP, why ? The simple answer is - I can. It is my environment and I have control over the whole shooting match, I can fiddle the apache config as necessary, I can easily add perl .pm's as needed. I am technically competent and used to working with non-trivial technologies. I work in the IT department of one of NZ's Universities, I have been here for years and consequently have watched and been involved with technologies that have come and gone. The latest area that our applications people are working with is using the web to deliver information from and interacting with our student management system, a large Ingres Database. The current application is run as a CGI and is written as a monolithic perl programme. Simply put, it is a disaster. The people who wrote it, learned perl as they went, and being fair to them, it works. Their architecture enabled them to add functions reasonably quickly, but the application does not scale. They are not using any database connection persistence at all and multiple concurrent session very quickly kill the web server, a high-end Compaq alpha. This application has seen us through the last 12 months but is hopefully to be replaced. With what ? Well, it would seem that no amount of arguing by the systems programmers or myself is going to be successful in getting them to continue with perl, but in a mod_perl environment. They are going to go the Java way, the reasons have all been stated in this thread before; Market hype, its an expensive solution so it must be good, its a cool new technology, you can't get good perl programmers, its what is being used by everyone else, we don't understand mod_perl ( they don't understand the java solution either ), we can buy the business logic we don't have to build it ... I like the perl/mod_perl solution, it works well for me, I believe it is also an appropriate technology for solving enterprise problems. The biggest hurdle we have faced in trying to get it considered has been market perception. If we had been able to find recognised or well-known enterprise/corporate/large site implementations to use as reference sites, it might have helped. To be able to say that site X uses a mod-perl solution and they are using Ingres/Oracle/Sybase or whatever and getting umpteen thousand hits a day gives the technology creditability. The Microsoft and Java marketing machines have given their technologies credibility (whether they deserve it or not is irrelevant). The decision has been made, unfortunately, so much of this is now water under the bridge but a list of reference sites might help others construct better cases for their management. -- Glen Eustace, Systems Engineer - Networking. Information Technology Services, Turitea, Massey University, Palmerston North, NZ. Ph: +64 6 350 5799 x 2707, Fax: +64 6 350 5607 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Thu, 7 Dec 2000, Jimi Thompson wrote: Everything required to make the module work ought to be included in the package or at least cross referenced to it. Newer versions of CPAN resolve dependencies for you, and you can always make a Bundle:: for your project. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
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]
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: 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: 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: 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: 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]
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: 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]
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]
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: 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]
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]
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]
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: 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]
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]
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]
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: 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: 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: 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]
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]
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: 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]
RE: mod_perl advocacy project resurrection
I would tend to agree with this on several points, but I have a few things to add (I didn't want this to be a "Me Too!" post.) A lot of the mindshare for this space has been taken over by Java. While some of you out there have actually tried to implement something in Java, then ran screaming back to Perl with your hair on fire, others aren't so "Lucky". I've been researching ecommerce and content management solutions for my company (take a guess who), and the Java technologies are *filled* with marketing hype that makes all the business users drool. I almost bought into it completely. I don't want to suggest that the Perl community should stoop as low as Java, but they have a very good thing going for them. They're presenting their data (very very skewed data, but data nontheless) in a very whizz-bang fashion, saying all the right words like "Inheritance", "Encapsulation", and bunches of other things that the marketroids gloss over at and think "Wow, this must be great stuff if I can't understand it!". What do we say with perl? "Scripting language", "Package", "Subroutine", "Array" and "Hash". While we can do almost everything that Java can do (we can, can't we?), we can do it a whole lot faster, in an easy-to-code fashion. I don't know what I'm getting at here, but I see that Perl is half a step behind Java in many ways, except for the performance issues (which perl is leagues ahead). For my company, we're probably going Java, but it sorta makes sense for us (we need an enterprise solution now...not when the Perl community gets around to it). Thanks for listening to my rant, and good hunting everyone! -man Michael A Nachbaur mike(at)nachbaur(dot)com http://www.nachbaur.com -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 05, 2000 6:50 AM To: mod_perl list Subject: RFC: mod_perl advocacy project resurrection Well as you've probably figured out, based on the load of email from me, I've dropped my last job, in order to finally finish the mod_perl book, have some rest and make a push to mod_perl. Yesterday I've updated the stats page: http://perl.apache.org/netcraft/ and the results are so-so, we go down on the number of domains. Which I suppose mainly caused by people reading the guide and deploying the front-end proxy solution, thus making mod_perl un-seen by various scanners like netcraft. In Paris we couldn't hire a single mod_perl programmer, because people don't even know what that. They know a lot about php and ASP. It's true that they don't even know what's Perl :( But, you all know that php pretty much takes over. Why? For two reasons: 1) initial corporate pushing (press/ads) 2) once well known, the word of the mouth does the rest. mod_perl lucks the corporate money/PR to get pushed. But we can still work on the exposure, which will bring corporate money/PR thru the word of the mouth. Luckily Matt has got sick of waiting for someone to work on the advocacy of mod_perl and he has just taken over it. Having a good informational site is good, but it's not enough. We need to solve the problem of people to find this site and wanting to use mod_perl. Solution? Spreading the word. I see two main streams: 1) Online zines. 2) Conferences. I think that we should start working on locating ezines wanting to publish mod_perl related articles (preferrably for a fee, to give incentives for others to write) and conferences where mod_perl can be relevant. The data is to be collected and distributed to the people who wish to advocate mod_perl, thru written articles and conference classes. I suppose that we will also look for companies who want to order mod_perl classes and find the teachers in the appropriate areas. May be we could organize some certification classes, to give more PR to mod_perl. I suppose that much more can be done. Comments are welcome. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
with your hair on fire, others aren't so "Lucky". I've been researching ecommerce and content management solutions for my company (take a guess who), and the Java technologies are *filled* with marketing hype that makes all the business users drool. I almost bought into it completely. I don't want to suggest that the Perl community should stoop as low as Java, but they have a very good thing going for them. They're presenting their data (very very skewed data, but data nontheless) in a very whizz-bang fashion, saying all the right words like "Inheritance", "Encapsulation", and bunches of other things that the marketroids gloss over at and think "Wow, this must be great stuff if I can't understand it!". What do we say with perl? "Scripting language", "Package", "Subroutine", "Array" and "Hash". While we can do almost everything that Java can do (we can, can't we?), we can do it a whole lot faster, in an easy-to-code fashion. sounds like we need a 'hacketer': hacker/marketer. any hackers out there with MBA's or is that an oxymoron? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
how about creating partnerships with companies (o'reilly, red hat, va linux, etc.)? i get email all the time promoting products and if one sounds interesting, i usually follow the link to check it out, especially if it's free and will help me do my job faster and/or better. some press releases to zdnet and some of the other main stream technical sites might get the name out there. probably the first thing to decide is who the target audience is and go from there. just some thoughts and distraction from the daily ho-hum. virginia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
Let me stright things out a bit, so you won't get misleaded by my post as a marketing call. What we want is very simple. 1. We want many users, so they will thoroughly test the software and spot bugs asap, so we -- current users will get a better product. 2. We want more developers, so they will write core mod_perl and 3rd party modules, again for us current users to re-use and save development time. The first item is directly linked to the second, as new developers come out from users. That's all. The advocacy project is about making people interested in perl and mod_perl, versus php and java. You see we just loose the testing power and development power because we cannot attract these people to join *our* community. So all the fuss is not about marketing, press and other commercial bullshit. It's about people since Open Source without people will not exist. If we don't ensure that there is a constant income of new people to the project, we cannot ensure the future of the project. I hope that our initiative is better understood now. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Michael Nachbaur wrote: I don't know what I'm getting at here, but I see that Perl is half a step behind Java in many ways, except for the performance issues (which perl is leagues ahead). For my company, we're probably going Java, but it sorta makes sense for us (we need an enterprise solution now...not when the Perl community gets around to it). How exactly does Java provide a better "enterprise solution" than Perl? And how can the Perl community better provide an "enterprise solution"? It is true that Java code is generally more cleaner and easier to maintain than Perl code, but this is because Perl allows you to write bad code, while Java enforces typing and OO design. A good Perl coder should be able to write code that is clean and easy to maintain by following coding guidelines, and by using OO modules and 'use strict'. I guess what I'm getting at is that I hear a lot of marketing hype about Java being a better "enterprise solution", but I'm curious as to what are the purely technical reasons for using Java over Perl. What exactly can you do in Java that you can't do as easily in Perl? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Stas Bekman wrote: What we want is very simple. 1. We want many users, so they will thoroughly test the software and spot bugs asap, so we -- current users will get a better product. 2. We want more developers, so they will write core mod_perl and 3rd party modules, again for us current users to re-use and save development time. The first item is directly linked to the second, as new developers come out from users. I think a good first step in that direction is to have mod_perl modules to do some of the basic things that early web developers want... a few really well documented and tailored-for-newbies modules. I think back a few years to "Matt's Script Archive", and what that did for perl and CGI. (Anyone for Apache::Formmail?) Just some stuff to get the new developer interesting in figuring out how to compile mod_perl, and to see the benefits of it. It could even be done with step-by-step examples, with gradually increasing functions. ( "Now move on to Guestbook-DBI" ... "Now add in Apache::Session for such-n-such functions" ) Perhaps even offer the same modules under mason, embperl axkit, etc. so folks can take a step in those directions too. I just think back to the time when I started putting smarts-to-web and these were the first steps I took, and I looked for that kind of hand holding as I figured out how to make it work. Jay Jacobs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
people won't use the software if you don't give them a compelling reason. mod_perl and the higher layer systems that use it are not as easy to configure or program as php, and they have a lot less support from external software vendors or relevance inside engineering shops than java. we are being squeezed from both ends. i had lunch with doug and jon swartz not too long ago, talking about the possibility of starting a web application infrastructure company based on mod_perl and mason. when we got down to it, the fundamental question was: why not just use java? and we couldn't find any answer other than "i like perl better". and that's not a reasonable business justification. at some point we're going to run out of hobbyists and others who /can/ justify using mod_perl-based technologies because they like perl better. On Tue, 5 Dec 2000, Stas Bekman wrote: Let me stright things out a bit, so you won't get misleaded by my post as a marketing call. What we want is very simple. 1. We want many users, so they will thoroughly test the software and spot bugs asap, so we -- current users will get a better product. 2. We want more developers, so they will write core mod_perl and 3rd party modules, again for us current users to re-use and save development time. The first item is directly linked to the second, as new developers come out from users. That's all. The advocacy project is about making people interested in perl and mod_perl, versus php and java. You see we just loose the testing power and development power because we cannot attract these people to join *our* community. So all the fuss is not about marketing, press and other commercial bullshit. It's about people since Open Source without people will not exist. If we don't ensure that there is a constant income of new people to the project, we cannot ensure the future of the project. I hope that our initiative is better understood now. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, brian moseley wrote: people won't use the software if you don't give them a compelling reason. mod_perl and the higher layer systems that use it are not as easy to configure or program as php, and they have a lot less support from external software vendors or relevance inside engineering shops than java. we are being squeezed from both ends. i had lunch with doug and jon swartz not too long ago, talking about the possibility of starting a web application infrastructure company based on mod_perl and mason. when we got down to it, the fundamental question was: why not just use java? and we couldn't find any answer other than "i like perl better". and that's not a reasonable business justification. at some point we're going to run out of hobbyists and others who /can/ justify using mod_perl-based technologies because they like perl better. You forget about satisfaction. Do you feel happier to program in Java than Perl? You want your employees to enjoy they work. We spend too much time working, I want to enjoy most of my working hours. You want me for my design and architecture skills, you have to give me something in return. For me salary is much less important factor than satisfaction. Therefore if the same job can be done with Perl and Java, why not to have your staff happy? That's the main point I think. Of course if the bussiness suffers because Perl is not good enough, that's a different point. Given that at least the same could be done with Perl and Java, Perl and PHP, Perl and whatever, I want to code in Perl. Therefore, we should make converts and when more people will prefer coding in Perl, because they *love* it and it's a legitimate choice, there won't be a question of whether I can afford doing this project in mod_perl, because there will be enough mod_perl programmers to take over it. So to answer your question, the complelling reason is joy and satisfaction. Given that other factors are at least compatible. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
stas said: What we want is very simple. 1. We want many users, so they will thoroughly test the software and spot bugs asap, so we -- current users will get a better product. 2. We want more developers, so they will write core mod_perl and 3rd party modules, again for us current users to re-use and save development time. The first item is directly linked to the second, as new developers come out from users. That's all. The advocacy project is about making people interested in perl and mod_perl, versus php and java. You see we just loose the testing power and development power because we cannot attract these people to join *our* community. So all the fuss is not about marketing, press and other commercial bullshit. It's about people since Open Source without people will not exist. If we don't ensure that there is a constant income of new people to the project, we cannot ensure the future of the project. I hope that our initiative is better understood now. ok, it sounds like 'marketing' is a dirty word. how about 'outreach'? i just don't see how you plan to attract all these fresh people without doing something to get the word out. putting links on perl sites is a great idea, but you're basically just trying to convert the converts. i agree that getting more people who use perl to adopt mod_perl is a necessity. these are the people who can contribute to development, thorough testing, and spotting bugs. to get 'many users', 'attract these people to join *our* community' and 'ensure that there is a constant income of new people to the project', you need to either convert the java/php people or grab the newbies who haven't chosen a technology yet. these people don't visit perl sites, as a rule. making installation and configuration as simple as possible, as suggested, is a great idea. but i still think that mod_perl/perl needs more mainstream exposure. i'm not talking about selling out, god forbid, but getting some positive press never hurt. would a link to perl/mod_perl books on a php/java book page at the o'reilly site be selling out? would a press release from some corporation stating that they use and have faith in the open souce mod_perl solution be commercial bullshit? maybe i AM missing the point, i don't know. thanks for listening. virginia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Stas Bekman wrote: Therefore if the same job can be done with Perl and Java, why not to have your staff happy? That's the main point I think. Of course if the bussiness suffers because Perl is not good enough, that's a different point. Given that at least the same could be done with Perl and Java, Perl and PHP, Perl and whatever, I want to code in Perl. exactly my point. and in my experience as well as that of many folks i've spoken with, it's just not the case. take CPTH web mail. we used Mail::Folder and MIME::*, but we had to write our own custom subclasses of all of them to deal with our mail store, with folder sorting, with mime tree caching, etc. and now that we're moving to an IMAP backend, we have to write a whole new custom set of subclasses based on Mail::IMAPClient. if we'd have been operating in a java environment, we'd have been able to take advantage of the "insanely great" JavaMail, which comes out of the box with an IMAP backend. a prototype IMAP re-implementation of our mail client took about 3 days, as opposed to the month or more it will take us to do the perl implementation. the availability of application server products in the java world is another example. go look at enhydra enterprise (http://www.enhydra.org/software/enhydraEnterprise/) and tell me that something like that exists in the perl world. and there are many products like this, both commercial and open source. competition flourishes, and the industry benefits. there are lots of folks on the market with experience developing for and operating weblogic. it's easier to hire and you get better time to market. you don't have to spend time re-integrating Apache::Session and Apache::DBI and Apache::WipeMyAss with each new project. this is why i think AO is some important, altho its scale is much smaller. it's a first step towards something like enhydra enterprise for those of us who would, all other things being equal, prefer to use perl. Therefore, we should make converts and when more people will prefer coding in Perl, because they *love* it and it's a legitimate choice, there won't be a question of whether I can afford doing this project in mod_perl, because there will be enough mod_perl programmers to take over it. So to answer your question, the complelling reason is joy and satisfaction. Given that other factors are at least compatible. yes, but we have to get to that point, and we're not there. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, brian moseley wrote: infrastructure company based on mod_perl and mason. when we got down to it, the fundamental question was: why not just use java? and we couldn't find any answer other than "i like perl better". and that's not a reasonable business justification. Isn't it theoretically the same thing in reverse at Java shops? "Why not use Perl? I like Java better." Each has its advantages. Perl is good for real programmers who are going to write code to actually solve a problem. Java is good for monkeys who think that buying a $100k app server and tweaking it via a monolithic API will give them what they want. But I might be biased. -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, Dec 05, 2000 at 11:34:49AM -0800, brian moseley wrote: people won't use the software if you don't give them a compelling reason. mod_perl and the higher layer systems that use it are not as easy to configure or program as php, and they have a lot less support from external software vendors or relevance inside engineering shops than java. we are being squeezed from both ends. i had lunch with doug and jon swartz not too long ago, talking about the possibility of starting a web application infrastructure company based on mod_perl and mason. when we got down to it, the fundamental question was: why not just use java? and we couldn't find any answer other than "i like perl better". and that's not a reasonable business justification. at some point we're going to run out of hobbyists and others who /can/ justify using mod_perl-based technologies because they like perl better. As sad as this makes me, it has a ring of truth. The only reason I use mod_perl is to do things that require an Apache module, and I don't feel like using C. I know the performance increase for mod_perl scripts is amazing, but the learning curve doesn't justify it. Perhaps if someone makes a mod_perl based embedded scheme like Cold Fusion or PHP, that has some special hooks into Apache for performance that the other solutions don't offer. . . Honestly, though, I didn't believe the strength of mod_perl rested on the Mason type modules. I thought the strength of mod_perl was having a perl/Apache API. Having an easy way to interact with Apache using everyone's favorite language was what sold me on Apache. Ideas? JJ -- J. J. Horner [EMAIL PROTECTED] "The people who vote decide nothing. The people who count the vote decide everything." - Josef Stalin "The tree of liberty must be watered periodically with the blood of tyrants and patriots alike. ... Resistance to tyrants is obedience to God." - Thomas Jefferson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, J. J. Horner wrote: Perhaps if someone makes a mod_perl based embedded scheme like Cold Fusion or PHP, that has some special hooks into Apache for performance that the other solutions don't offer. . . how is mason not like this? Honestly, though, I didn't believe the strength of mod_perl rested on the Mason type modules. I thought the strength of mod_perl was having a perl/Apache API. Having an easy way to interact with Apache using everyone's favorite language was what sold me on Apache. we very rarely use the apache api anymore. i prefer the abstraction layer of a templating engine, for ease of use and for maintainability by larger teams. i used to be shocked that nobody i worked with wanted to learn how to configure apache or use its api. now i'm right there with them. give me Apache::Request and mason and i'm happy. i know there are several people on the list who swear by "all handlers, all the time". i've never heard anybody give a reason for that preference that actually made sense to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Dave Rolsky wrote: Each has its advantages. Perl is good for real programmers who are going to write code to actually solve a problem. Java is good for monkeys who think that buying a $100k app server and tweaking it via a monolithic API will give them what they want. c'mon dude, offer something constructive to the thread or stay out of it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
"Thomas J. Mather" wrote: On Tue, 5 Dec 2000, Michael Nachbaur wrote: I don't know what I'm getting at here, but I see that Perl is half a step behind Java in many ways, except for the performance issues (which perl is leagues ahead). For my company, we're probably going Java, but it sorta makes sense for us (we need an enterprise solution now...not when the Perl community gets around to it). Server side performance of Java shouldn't be an issue for you. How exactly does Java provide a better "enterprise solution" than Perl? And how can the Perl community better provide an "enterprise solution"? I've worked with both (Java 2 EE and tools like Apache::ASP/Mason). What people want out of an "enterprise solution" is a middle tier which is not tied into the presentation. When you free your process decisions from the presentation in that way, you can implement a B2B type transactions much more easily. The rationale for J2EE is already defined quite well in this way. snip I guess what I'm getting at is that I hear a lot of marketing hype about Java being a better "enterprise solution", but I'm curious as to what are the purely technical reasons for using Java over Perl. What exactly can you do in Java that you can't do as easily in Perl? Transaction support for your business logic is easy in J2EE. It's not clear how you do this in Perl? By CORBA ORBs and TMs I suspect, but there's no real standard framework for that in Perl. There are other lesser advantages too... standardized XML support is one of them (topical for me right now). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Stas Bekman wrote: On Tue, 5 Dec 2000, brian moseley wrote: people won't use the software if you don't give them a compelling reason. mod_perl and the higher layer systems that use it are not as easy to configure or program as php, and they have a lot less support from external software vendors or relevance inside engineering shops than java. we are being squeezed from both ends. i had lunch with doug and jon swartz not too long ago, talking about the possibility of starting a web application infrastructure company based on mod_perl and mason. when we got down to it, the fundamental question was: why not just use java? and we couldn't find any answer other than "i like perl better". and that's not a reasonable business justification. at some point we're going to run out of hobbyists and others who /can/ justify using mod_perl-based technologies because they like perl better. You forget about satisfaction. Do you feel happier to program in Java than Perl? You want your employees to enjoy they work. We spend too much time working, I want to enjoy most of my working hours. You want me for my design and architecture skills, you have to give me something in return. For me salary is much less important factor than satisfaction. Therefore if the same job can be done with Perl and Java, why not to have your staff happy? That's the main point I think. Of course if the bussiness suffers because Perl is not good enough, that's a different point. Given that at least the same could be done with Perl and Java, Perl and PHP, Perl and whatever, I want to code in Perl. I know this goes a little off topic, so I apologize in advance. One big sticking point with Perl I'm just starting to run into is XML. Yes, Perl has great XML modules, and many more promising ones. But where is the _validating_ XML parser? I'm doing some XML work where a validating parser would be very nice, speed hit or not. I can work around it easily (this is perl :-), but it would save me some work. The XML Java combination has a LOT more corporate resources (read $$$) focused on it than Perl XML. How many Java-based XML software announcements have you seen lately? Now compare that to Perl-based XML modules. The numbers don't compare very well. What can we do about this? I can't help write a validating parser, but I would be happy to help test it out. IMHO, more XML support would help sell perl into more corporate settings. Java is big into buzzwords, and XML is one of the biggest there is at the moment. And as we know PHBs like buzzwords, so that is one more point in Java's favor. I'm quite happy being a perl programmer, although I do plan on learning other languages in the future. I love perl. As such, I'm definately all for keeping my future job market as large as possible. If getting perl more into the corporate eye helps that goal, then what do I need to do as a "little guy"? -- Drew Taylor Software Engineer OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, brian moseley wrote: the availability of application server products in the java world is another example. go look at enhydra enterprise (http://www.enhydra.org/software/enhydraEnterprise/) and tell me that something like that exists in the perl world. http://www.mediasurface.com Sadly though, its only one product in a sea of Java products. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
brian moseley writes: bm i know there are several people on the list who swear by "all bm handlers, all the time". i've never heard anybody give a reason bm for that preference that actually made sense to me. i'm not sure about "all handlers, all the time" but a good deal of what i'm using mod_perl for is session management, credential maintenance, custom logging, on-the-fly compression, and other "housekeeping" tasks. i think only 10% of my handlers are content handlers, the other 90% do things neither CGI nor an application server are going to do. if for no other reason than time to market, it's nice to have access to the server API in Perl rather than C. it took only hours to whomp up handlers to help integrate netegrity's siteminder product into our existing site; it would have been weeks if it had to be written in C. cheers, k. -- kevin montuori support independent booksellers -- http://www.booksense.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000 12:40:47 -0800 (PST), brian moseley wrote: On Tue, 5 Dec 2000, Dave Rolsky wrote: Each has its advantages. Perl is good for real programmers who are going to write code to actually solve a problem. Java is good for monkeys who think that buying a $100k app server and tweaking it via a monolithic API will give them what they want. c'mon dude, offer something constructive to the thread or stay out of it. Except that he's absolutely right. I have personal experience -- my company is ripping out its elegant mod_perl based architecture and replacing it with *cough* the j-word *cough*. mod_perl is the superior technology, hands down. This is coming from someone who's an avowed perl hater, too. I loathe perl itself, but have to admit that mod_perl, when you compare it to the alternatives in the dynamic-web-content space, just plain rules. Just one example... my company ran into a bug in mod_perl a while ago... so what did we do? we fixed it, and submitted a patch. If we'd been using the J-word, we'd have been stuck. Tell me one big-name app server that's written in C and that'll let you download the source and fix bugs. disney gratuitous="yes" Kinda hard to laugh hangin' there in one o' them "virtual machines", Rob... /disney ~Ben (this message comes guaranteed to offend absolutely everybody in some fashion or other) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
The issue here is not the underlying architecture. I have seen so-called "Enterprise" solutions which are based on the most flakey of ideas, but are sold with a $150k+ pricetag. Why? Because of the integraiton. Because of the support. I a large company, you cannot *afford* to have the ubergeek cureall solution. What if the guy gets hit by a bus? What if he goes to another company? You can't afford that kind of situation. What do you do in that case? Make the system easy enough to use and understand, that you can have 5-ubergeek types at the company. Sure the system isn't a screamer, but atleast it doesn't take a genious to understand. Also, systems like EmbPerl, HTML::Mason and Axkit/Cocoon work wonders for shops with under 10 developers. What happens when you have 20 programmers, 15 workflow people, 45 content creators, 10 photographers, 20 HTML designers / producers, 30 merchandisers, 30 marketers and a host of misc. consultant copywriters? How do you coordinate everything? A large online retailer, news site, portal, you name it...has a *lot* of employees. *That* is what an Enterprise is...and anyone who says you can "get by" with an HTML::Mason is diluted. Now, I use HTML::Mason, and I love it...for my personal website. I'm sure many organizations can get by with it. But, thats not what I'm talking about, and thats where Java is winning. What happens when all those programmers working on Java solutions decide to build something at home? They'll use Java. If you remember, Apple tried to appeal to schools and home users, and M$ focused on business. Who has all the marketshare now? The answer isn't in the hobbiest or in the small sites. For longevity and mindshare, you must go into the big businesses. My company is a Perl shop, through and through. We would rather go to Perl, but the problem is that theres *nothing* out there. Please prove me wrong. --man Michael A. Nachbaur -Original Message- From: Thomas J. Mather [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 05, 2000 10:25 AM To: [EMAIL PROTECTED] Subject: Re: mod_perl advocacy project resurrection On Tue, 5 Dec 2000, Michael Nachbaur wrote: I don't know what I'm getting at here, but I see that Perl is half a step behind Java in many ways, except for the performance issues (which perl is leagues ahead). For my company, we're probably going Java, but it sorta makes sense for us (we need an enterprise solution now...not when the Perl community gets around to it). How exactly does Java provide a better "enterprise solution" than Perl? And how can the Perl community better provide an "enterprise solution"? It is true that Java code is generally more cleaner and easier to maintain than Perl code, but this is because Perl allows you to write bad code, while Java enforces typing and OO design. A good Perl coder should be able to write code that is clean and easy to maintain by following coding guidelines, and by using OO modules and 'use strict'. I guess what I'm getting at is that I hear a lot of marketing hype about Java being a better "enterprise solution", but I'm curious as to what are the purely technical reasons for using Java over Perl. What exactly can you do in Java that you can't do as easily in Perl? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, (Matthew Kennedy) wrote: I guess what I'm getting at is that I hear a lot of marketing hype about Java being a better "enterprise solution", but I'm curious as to what are the purely technical reasons for using Java over Perl. What exactly can you do in Java that you can't do as easily in Perl? Transaction support for your business logic is easy in J2EE. It's not clear how you do this in Perl? By CORBA ORBs and TMs I suspect, but there's no real standard framework for that in Perl. There are other lesser advantages too... standardized XML support is one of them (topical for me right now). XML support I think we have mostly covered now (or maybe you disagree?). But I'd really love to hear some rational discussion on transaction object support. There are open source J2EE implementations - would it be possible to look a porting the transaction management components of that to Perl? Would this be desirable? Personally I put all transaction critical stuff in the database, and rely on RDBMS transaction support, but I've never done J2EE, so I'm curious as to the advantages. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Matt Sergeant wrote: On Tue, 5 Dec 2000, brian moseley wrote: the availability of application server products in the java world is another example. go look at enhydra enterprise (http://www.enhydra.org/software/enhydraEnterprise/) and tell me that something like that exists in the perl world. http://www.mediasurface.com Sadly though, its only one product in a sea of Java products. doesn't look like enhydra enterprise at all. i'm not talking about a content management system, i'm talking about a scalable middle tier service upon which any type of application can be built. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, kevin montuori wrote: i'm not sure about "all handlers, all the time" but a good deal of what i'm using mod_perl for is session management, credential maintenance, custom logging, on-the-fly compression, and other "housekeeping" tasks. i think only 10% of my handlers are content handlers, the other 90% do things neither CGI nor an application server are going to do. in fact, these are exactly the problems ao is meant to solve. the idea is that for now, we provide a presentation tier environment with hooks to allow you to integrate middle tier functionality, but eventually it would be nice to also create a real j2ee like environment with separate front and middle tiers, where presentation and business logic can be varied and scaled separately. if for no other reason than time to market, it's nice to have access to the server API in Perl rather than C. it took only hours to whomp up handlers to help integrate netegrity's siteminder product into our existing site; it would have been weeks if it had to be written in C. yup, it's always going to be nice to have direct access to low-level components. as someone pointed out earlier, some people will always require it. i'm shooting to make 80% of people happy rather than 20%. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
barries wrote: On Tue, Dec 05, 2000 at 04:10:01PM -0500, Drew Taylor wrote: I know this goes a little off topic, so I apologize in advance. One big sticking point with Perl I'm just starting to run into is XML. Yes, Perl has great XML modules, and many more promising ones. But where is the _validating_ XML parser? Will XML::Checker::Parser do? Hmmm, looks interesting. I'll check into it. Any experience (good or bad) with it? I see that it relies on XML::Parser. How well does XML::Parser handle the newly available external DTD feature? I'm doing some XML work where a validating parser would be very nice, speed hit or not. I can work around it easily (this is perl :-), but it would save me some work. plugAnd, if you want to validate while writing, XML::ValidWriter might help/plug. My biggest problem with XML::Writer (and hence XML::ValidWriter) is that I can't write to a string, unless there is some hackish workaround. I remember someone talking about an IO::String sort of module, but it sounds like using a sledhammer to drive a nail. ;-) I did actually check out XML::Writer, and even went to far as to replace the IO handle stuff with a plain old string. But then decided to use something else. While I love the idea of validating as I write XML, it doesn't help on the other end. :-( -- Drew Taylor Software Engineer Phone: 617.351.0245 Fax 617.350.3496 OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
On Tue, 5 Dec 2000, Matthew Kennedy wrote: I've worked with both (Java 2 EE and tools like Apache::ASP/Mason). What people want out of an "enterprise solution" is a middle tier which is not tied into the presentation. When you free your process decisions from the presentation in that way, you can implement a B2B type transactions much more easily. The rationale for J2EE is already defined quite well in this way. Mr. Mather's Apache::PageKit module does a good job of implementing the model/view/controller paradigm in mod_perl. Transaction support for your business logic is easy in J2EE. It's not clear how you do this in Perl? Use an RDBMS. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
