Re: Apache V2 and Mod_Perl Question
At 04:46 PM 7/5/2001 -0500, Purcell, Scott wrote: Hello, NT question. I believe that Apache 2 is out for NT, and was wondering if apache 2 works with mod_perl? I am running Apache 1.3.20 and mod_perl 1.25_01-dev. Can or should we start converting to Apache 2? Just curous about some time frames for this. Thanks Scott Purcell Apache 2.0 is still in beta and could be for a long time. mod_perl 2.0 will be in alpha/beta until Apache 2.0 is actually released and I am not aware of a timeframe for Apache 2.0 being released. Although perhaps it's possible that someone else knows something about Apache 2.0 timelines getting solidified. Like the release of the Linux kernels, I suspect the answer to the schedule is that it will be released when it's ready. :)
Re: [OT]: Re: Just a few good men? Was: ignored (again)
At 06:35 PM 7/5/2001 -0500, Jimi Thompson wrote: Gunther, I think that mentions in publications like Ziff-Davis, CMP.net, maybe SysAdmin. However, the techies know mod_perl and love it. It's the PHB's that we need to convince of the merit of our chosen platform. Therefore, it also needs to make it into the rags that management reads like Forbes, Barron, New York Times, etc. SO if anyone knows of any reporters for these rags, we need to educate them so they can write a really good article. And the articles need to keep coming. Then maybe the PHB's will fall into line. Just an idea. The problem is that setting up a web site is not mainstream news. Nor is having an application server out. This is tech news and even then there are a lot of app servers and a lot of web apps out. You need to have some business angle. As a tech company, we deal with this all the time -- how do we get ourselves in the press? Our technology may be cool, but it's not really news-worthy in either Perl or Java. So we get ourselves in the press by aligning ourselves with jobs that may have news-worthy significance. For example... http://asia.internet.com/asia-news/article/0,3916,161_793941,00.html An article that is about a new type of service that hasn't been offered before in Malaysia. But with enough twists to get our own name in the news in agreement with the client with whom we did the work when we were able to craft a press-release. So similarly, I think a key point is to get Perl news about how it affects real business bottom line. This is similar to a talk we gave at PerlCon two years ago about Perl in the investment banking community. And it was the primary purpose behind a book that I wrote a chapter for called Applied Perl. The idea is that it is a book with chapters written by all sorts of people from all types of backgrounds, writing about how they use Perl (plus source code!) in their specific businesses from investment banking to the entertainment industry to mobile phone computing. Anyway, I am really happy that a publisher took us up on the book (originally Peter Williams, myself, and Selena Sol were shopping it around and then Peter Williams took over as the editor (we wrote for it but declined editing due to lack of time)) because I think it continues to show more about how Perl pervades every industry and walk of life. AND as a shameless plug, if the book is purchased enough, perhaps they'll want a follow-up which will advertise Perl even more. As a disclaimer, I make no money on additional sales of the book, I just wrote the chapter for a flat rate. :) Jimi - Original Message - From: mailto:[EMAIL PROTECTED]Gunther Birznieks To: mailto:[EMAIL PROTECTED]Matt Sergeant ; mailto:[EMAIL PROTECTED]Joachim Zobel Cc: mailto:[EMAIL PROTECTED][EMAIL PROTECTED] Sent: Thursday, July 05, 2001 6:24 AM Subject: [OT]: Re: Just a few good men? Was: ignored (again) At 07:44 AM 7/5/2001 +, Matt Sergeant wrote: On 04 Jul 2001 17:31:24 +0200, Joachim Zobel wrote: Hi. The question is: Are a few good developers all we need? If this is the case we can safely ignore to be ignored (we have them). It is OK to be one of the few people to know the leading Apache development system. But it has serious drawbacks. Where I work people are migrating from server side javascript to java. With better Perl marketing they might migrate from Perl/CGI to mod_perl and my work would be more fun (I do consider changing my job an option, but I like the people I work with). It is however frustrating to leave work, get on the tram, take out my laptop and do it better than I did the 8h before. So do we want to be Enterprise and Industry Standard and such crap? Yes, we do. But I don't think it's enough to convince people to move to mod_perl. They want to move to a better framework. I'm sure you know which one I favour :-) Sadly most people *still* see Perl on the web as CGI, as printing out your HTML from code, etc. It needs more articles in the right places to fix that sort of misconception. Matt. This is really off topic. Anyway, so what are the right places for those articles? Microsoft Systems Journal? :) And what should we do to get the articles in the right places? __ Gunther Birznieks (mailto:[EMAIL PROTECTED][EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/http://www.eXtropia.com/ __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: rand bug?
Your problem is likely that the use of a global my is creating a closure
(see mod_perl guide). Replace it with use vars qw($rand); and don't declare
your globals using my.
At 01:07 PM 7/6/2001 -0500, Purcell, Scott wrote:
Hello,
rand bug with mod_perl?
my $rand = int(rand(1000)) always produces '2' under mod_perl.
I have noticed that if I ask for the line above, it always puts $rand at a
'2'? So I did some test below, looping through and the first time through
with mod_perl, the number is always 2?
Under investigation when I run the following code under cgi-bin, it works
good like it should.
960 is tmp
240 is tmp
193 is tmp
197 is tmp
When I run that same code under mod_perl, it looks like this:
2 is tmp
564 is tmp
194 is tmp
809 is tmp
So basically if I just need one random number I have to do some excess work?
Does anyone know why this is?
If anyone wants just drop the following line under cgi-bin and mod_perl and
you'll see the results.
Please let me know,
Scott
#! perl
use CGI qw/:standard/;
my $q = CGI-new;
print $q-header();
print $q-start_html(hello);
foreach (my $i=1; $i5; $i++) {
my $tmp = int(rand(1000)+1);
print $tmp is tmpbr\n;
}
Scott Purcell
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Re: Apache::SimpleTemplate
At 06:16 PM 7/7/2001 -0700, brian moseley wrote: On 7 Jul 2001, Randal L. Schwartz wrote: Yes. Writing a templating system in Perl is trivial. Writing a *useful* templating system in Perl is demonstratably hard. unless you keep application features in a separate layer from the templating system (eg the servlet api ;) I think it is still quite difficult. Even if you have servlets, for example, adding JSPs was quite a task. At issue is providing a minimal API yet still allow the templates to do things that weren't originally intended. In addition one of the criteria for useful to me is fast. If the template system is slow, it's quite annoying. However, this goes against other people's ideas of useful being full featured. As Steven Wright says (paraphrased) if you had everything where would you put it? So to make something that is powerful yet fast is quite the challenge. And then there are architectural tradeoffs as to the type of application that the template is being used for. Transactions? Portal based? Integrating many apps together? Standalone? Later, Gunther
OT: Re: ApacheCon Dublin Cancelled?
At 03:44 PM 7/15/2001 +0100, Matt Sergeant wrote: Looks like Camelot, the organisers of ApacheCon (and other conferences, such as XML Dev Con - a conference I've spoken at a number of times), are going out of business. Those of you who know the employees at Camelot will Odd, I got the letter for ApacheCon speakers talking about payment to speakers which I would think you got as well. know they always went out of their way to help the speakers at various conferences, and I would venture to say they were one of the better organised conferences I've attended. Sad to see them go. I too am sad. I did not know the conference producers well, but I personally thought the plane + hotel + conference fee paid to all speakers EVEN 1 HOUR talk speakers was really generous. I can usually understand paying those things for tutorial speakers, but giving all that for 1 hour talk speakers was amazingly generous though. But I guess too generous. Anyway, lately conference attendence is down, so naturally vendors don't want to spend a lot of money on advertising at a conference, so naturally there's less money to pay for speakers, so naturally less people want to attend with less speakers, etc I hope the downward trend doesn't continue with other good conferences. :(
RE: BOF?
At 01:19 PM 7/14/2001 -0400, Geoffrey Young wrote: -Original Message- From: Ken Williams To: modperl Sent: 7/14/01 11:48 AM Subject: BOF? Yo, I just noticed that there's no mod_perl BOF listed at http://conferences.oreillynet.com/cs/os2001/pub/10/bofs.html . Is one scheduled? If not, let's get one together. I thought Gunther was in charge this time ;) Ah... I thought I was just looking into the T-Shirts. :) Anyway, the T-Shirts aren't a go this time anyway because of a lack of someone to pay for them. I'd like to have sponsored but we're paying (to various degrees) for 3 people to attend the conference this year so that didn't work out either. If you like, I guess I could try organizing to get a BOF room? The only mod_perl BOF I attended was last ApacheCon which was by the pool with drinks. I think that was very nice. :) I wonder if we can reserve the pool and drinks being brought to us for the BOF this year instead a stuffy room. :) Is there a reason for actually getting a mod_perl BOF room? ie are there announcements to make that wouldn't be made at Doug's 2.0 talk or through the mod_perl track? Or would it just be a place to gather before finally heading off someplace else? Later, Gunther PS I am in DC all week on vacation before the conference so I can probably help out a bit.
Re: BOF?
At 12:10 AM 7/16/2001 -0500, James G Smith wrote: Matt Sergeant [EMAIL PROTECTED] wrote: On Sat, 14 Jul 2001, brian moseley wrote: On Sat, 14 Jul 2001, Ken Williams wrote: I just noticed that there's no mod_perl BOF listed at http://conferences.oreillynet.com/cs/os2001/pub/10/bofs.html . Is one scheduled? If not, let's get one together. speaking of which. there should be an opening night piss-up, eh? somebody that knows the area should propose a place. Judging by where the hotel is, I think probably the hotel bar is going to be best. I arrive on Sunday. As do I. Just let me know where and when. I will be in around 1pm on Sunday for those that want to do a late lunch. I think that Philippe and Stas will be around also. Definitely night time drinks would be great on opening night...
Re: OT: Re: ApacheCon Dublin Cancelled?
At 11:31 AM 7/16/2001 -0700, Bill Moseley wrote: At 10:46 AM 07/16/01 -0600, Nathan Torkington wrote: Are there any requests other than price for next year? What would you like to see? What could you do without? Well, this is more along the price issue that you don't want to hear about, but I much prefer a single fee for everything instead of separate tutorial and conference fees. I understand the scheduling hell, but I like the flexibility to decide what to attend during the conference. What I attend in the morning may influence what I attend in the afternoon. I am misunderstanding this perhaps. Don't you get this anyway by getting a slightly larger discount for taking the tutorial and the conference together? ie is that what you are asking for? To combine the fees so that it is cheaper? And these days more and more people may find themselves like me, paying their own way. I'm very disappointed that I had to cancel after adding everything up. In today's economy it's perhaps true. In the economy of 2 years ago, it seems like a business would consider it a perk to send their developer to a conference because they were scrambling to keep their programmers anyway they could (conferences is one way if their organization won't allow a raise in salary). But now many programmers are fortunate to have a job. Although there are still pockets of companies willing to pay for conferences, it's probably quite lower. Well, at least if you want a cheap conference there is always YAPC. I would suspect the O'Reilly brand unfortunately probably prevents doing things that involve having a truly on-the-cheap conference. Of course, by cheap I don't mean bad. Just a different way of handling a conference and a different vibe/level of coordination and # of talks etc... Later, Gunther
Re: OT: Re: ApacheCon Dublin Cancelled?
At 10:46 AM 7/16/2001 -0600, you wrote: Matt Sergeant writes: I doubt it's the last one we'll see fall... I suspect TPC will be a shadow of its former self... :( for four years arguing that it should be cheaper. If you feel that there'd be more attendees at a lower price, then I suggest you tell that to every O'Reilly conferences person you see at TPC (except for me :-) Are there any requests other than price for next year? What would you like to see? What could you do without? I'd like to know more about suggestions to make these suggestions? Is it really as simple as me going to another O'Reilly person or filling out an apres-conference survey form and saying More attendees for less money. Or is there anything more concrete that would help it more? I am just afraid that simply stating this, I would not be taken seriously because it seems so obvious. But how do you get more attendees? Will they definitely come if it is less money? And if so, how much less? I am not a marketing person, so I am really bad at figuring out how to map this concretely, but I am not sure that there is an obvious price point where someone would attend or not attend. For example, let's say the conference costs $1000 and 1000 attendees attend? At that point it is $1,000,000 to hold the conference. And let's just say that's what you need to pull it off. But if you lower the cost by 10% to $900, then you've lost $100,000. So you need at least another 120 or so attendees to make up the cost. But will you get more attendees? Although you lowered the price by 10%, the hotel and the plane remain a fixed cost. Let's say it is $1000 for the hotel and $500 for the plane? Then a 10% drop a $1000 conference fee becomes less than a 5% drop in the overall cost and no more attendees may actually come. Anyway, here are some suggestions I would personally have to make it easier to attend conferences like this. Although perhaps they have already been thought about in the past and discarded for good reasons by people who know more about conference organization than I do... :) Note that some ideas are more radical than others and reflect that I am just shooting some ideas out. 1) More Student Discount (If none already) I don't know if this is currently the case, but I think people who are true full-time students should be allowed to attend at a significantly reduced cost. Part of open source and Perl advocacy is getting the young generation hyped so that they will want to continue to carry the torch. My gut feeling is that full-time students don't tend to attend these expensive conferences anyway because it's their parent's that they would have to convince. So offering them a low enough ticket cost to basically cover expenses will still contribute to the bottom line yet get a new round of attendees. And next year they may be out of school with a full time job that would be willing to pay for them. So it primes a set of attendees to continue attending. 2) I found the hotel costs really high. A good chunk of the entire cost of going to the conference is the hotel. I think Nat posted on this list, alternatives which was great. But I actually wish I knew the alternatives before I had signed up. I emailed someone directly in the beginning asking for alternatives because I come from Singapore where the currency is much less than your US currency, but did not get any alternatives. Since I didn't know the area and don't have a travel agent I trust to really know the hotel geography relative to the conference, I just reached out of my ass and paid the high cost of being in THE conference hotel. Of course, I do prefer to be at the conference hotel because it's more fun to be close to the action, it would have been nice to have been given a choice. I know that you guys probably get a lot of discount from Sheraton by having them be the only hotel on the listed on the Web for the conference, but it isn't at all convenient for conference attendees. Why should each attendee manually call another travel agent to find out alternative hotel costs (and not all travel agents REALLY know the area well) individually when OReilly could be posting alternatives. After all, you guys actually walked around the area and scouted out for facilities and probably know what the hotel and conference situation is truly like better than many travel agents sitting in their big office buildings taking calls all day. I just think that if you could provide a hotel that is like 3/4 the price then you make the entire package (Hotel, Flight, Conference fee) that much more attractive WITHOUT lowering the cost of the conference itself. If sponsorship of the hotel is a problem, maybe they would be OK with a link at the bottom that says Cheap People Click Here. And it would take you to a page that explains the true alternatives for the area if you can't afford to be in THE hotel. That would certainly help the bottom
Re: cgi-lib.pl
Rather than go into the details, it's probably best that you use Apache::PerlRun in place of Apache::Registry. cgi-lib.pl is an old Perl 4 library, if you are using new Perl 5 features like OO, modularity, and want to take the MOST advantage of mod_perl, use CGI.pm instead. CGI.pm also has a backwards compatible mode for cgi-lib.pl scripts. Also please read the mod_perl guide. http://perl.apache.org/guide/ At 01:03 AM 7/24/2001 -0500, John Buwa wrote: Hello, I have a huge system i wrote using the cgi-lib.pl as its core. I attempted to integrate mod-perl with my system and all my cgi-lib.pl which are used via a require in all scripts returns errors. My dont work, if they do the act very strange and unacceptable. My question is how do i use cgi-lib.pl and mod-perl together? Is anyone doing this? How can it be done. Here is a common error in my log: [Mon Jul 23 05:38:06 2001] [error] Undefined subroutine Apache::ROOTwww_2emy_2ddomain_2ecom::cgi_2dbin::pads::welcome_2epl::ReadPar se called at /driveb/usr/web/webroot/cgi-bin/pads/welcome.pl line 7. Any info would be appreciated! John __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: [ANNOUNCE] RoboWeb 1.0b, web application test suite generator
If you guys end up finally collaborating, one very minor request I would have is that it goes into CPAN as something more standard like WWW:: namespace rather than a marketing name like RoboWeb. RoboWeb is actually a good product name (and in fact do a search on google for other tools with a RoboWeb label attached to them), but it really opens up room for misinterpretation in the future. And personally, I think these seem like indispensable tools that should be a standard CPAN addition. Calling it RoboWeb on CPAN will make it as confusing as figuring out which template solution to use -- but I suspect that web testing features can be fairly standardized (unlike templates). At 11:53 AM 7/23/2001 +0400, Ilya Martynov wrote: We should investigate how these 2 projects can work together when I'm done so that RoboWeb 'recorded' sessions can create WWW::Automate methods that utilise the structure of the page. The benefits of doing this are: 1- Resultant scripts are easier to interpret 2- Scripting apps that vary their form field names works. CG [..skip..] CG I look forward to seeing WWW::Automate and to working together on this. I've recently become maintainer of another testing module HTTP::WebTest. Stable version (released on CPAN) already has many interesting features (like response time tests, text matching tests, content size checks, support for both remote web server and local test modes). I'm working on its rewrite in modular style where tests modules are pluggable so it will be easily extendable. After finishing with it I thought about writhing proxy that records users actions and produces skeleton of test. Maybe joining our efforts have some sense. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: [OT] Using mod_proxy and mod_ssl to forward SSL connections
The front end server must be configured to understand SSL. Otherwise, how else can the HTTP request be pulled apart (decrypted) to understand that it has to be forwarded to the backend server. If you configure the back-end server to understand SSL, that's OK, but beware that all mod_proxy is doing is establishing one SSL connection from browser to mod_proxy and then a brand new SSL connection from mod_proxy to the backend server. 2 separate SSL sessions because SSL cannot (ie inconvenient to) be man-in-the-middled. It has some likelihood to also to be inefficient because I am not entirely sure that mod_proxy is caching the SSL client session key that it generates to connect to the back-end server as the browser normally does for the front end. At 03:26 PM 7/25/2001 +0200, Issac Goldstand wrote: I am trying to make a back-end mod_perl/mod_ssl server. The front-end server that is currently in place is doing a great job forwarding normal requests to the back-end, but it is not forwarding SSL. Now, the front-end server does not understand SSL, itself. What I'm doing is trying to force the entire VirtualHost listening on port 443 to an IP on a private subnet on an obscure port (what I do for all the back-end servers. There are actually 3 of them doing various things). But it won't work. The strange thing is that if I go to http://mysite:443/ I get the default Apache It Worked page, but https://mysite/ generates an error saying that the front end cannot understand, which seems to be pointing at the fact that it's not forwarding ANYTHING to the back-end server... Stas Eric: This situation is mentioned in your book, but in nowhere enough detail. IMHO, that segment of the book (near the end of chapter Server Setup Strategies for the Best Performance) should be redone in better detail to explain forwarding SSL to the back-end server. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: [OT] Using mod_proxy and mod_ssl to forward SSL connections
At 07:05 PM 7/25/2001 +0200, Issac Goldstand wrote: The front end server must be configured to understand SSL. Otherwise, how else can the HTTP request be pulled apart (decrypted) to understand that it has to be forwarded to the backend server. 2 words: dumb proxy. The request doesn't need to be pulled apart by the front-end server in this case. The entire virtualhost is supposed to be tunneled directly to the back-end server. That's what I'm trying to figure out how to do... I see. I don't know if that will work. The connect header is a special proxy feature to allow a proxy to just pass through all the TCP level packets instead of opening a separate SSL client connection. But from a reverse proxy perspective, I am not sure that mod_proxy is automatically given this special header by the browser as it might if you configured IE or Netscape to use a physical proxy server. But it definitely won't work based on the HTTP Hostname parameter because SSL has to be established before any other HTTP header other than the weird connect one is decoded. If you configure the back-end server to understand SSL, that's OK, but beware that all mod_proxy is doing is establishing one SSL connection from browser to mod_proxy and then a brand new SSL connection from mod_proxy to the backend server. 2 separate SSL sessions because SSL cannot (ie inconvenient to) be man-in-the-middled. I know that. The key is (and must be) on the back-end server. Which is why I'm trying to do it this way. The mod_perl book seemed to imply that this was possible, and I _know_ that mod_proxy is supposed to recognize CONNECT requests for this very purpose - it says so in the manual... I just don't know how to set it up properly... It has some likelihood to also to be inefficient because I am not entirely sure that mod_proxy is caching the SSL client session key that it generates to connect to the back-end server as the browser normally does for the front end. I'm not even sure that mod_proxy can be it's own SSL client... The documentation says it knows how to handle incoming CONNECTS, but I'm not sure that it could make its own HTTPS request... If you try it, I think you will find that this works. If you compile in mod_ssl, mod_proxy can establish SSL connections to the back-end. The only thing you lose other than performance is the capability of passing a PKI certificate through the proxy (since decoding and establishing a new SSL connection would be considered a man-in-the-middle attack). When you don't care about client certificates, it really doesn't matter that the reverse proxy is in the middle because the reverse proxy has the valid server certificate that your client is pre-programmed to understand is a valid certificate (eg from Verisign). Really, the cleanest way of doing what you want is to run the SSL engine on the front-end and then proxy (convert) back the connection to the backend as HTTP. If you are using some authentication on the front-end (eg client certificates) there are modules which will allow you to take a USER_DN and pass it to the back-end server as an addition parameter (eg using mod_rewrite) or as another custom HTTP header. Issac At 03:26 PM 7/25/2001 +0200, Issac Goldstand wrote: I am trying to make a back-end mod_perl/mod_ssl server. The front-end server that is currently in place is doing a great job forwarding normal requests to the back-end, but it is not forwarding SSL. Now, the front-end server does not understand SSL, itself. What I'm doing is trying to force the entire VirtualHost listening on port 443 to an IP on a private subnet on an obscure port (what I do for all the back-end servers. There are actually 3 of them doing various things). But it won't work. The strange thing is that if I go to http://mysite:443/ I get the default Apache It Worked page, but https://mysite/ generates an error saying that the front end cannot understand, which seems to be pointing at the fact that it's not forwarding ANYTHING to the back-end server... Stas Eric: This situation is mentioned in your book, but in nowhere enough detail. IMHO, that segment of the book (near the end of chapter Server Setup Strategies for the Best Performance) should be redone in better detail to explain forwarding SSL to the back-end server. Issac Internet is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint: 7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology
Re: [OT] Using mod_proxy and mod_ssl to forward SSL connections
At 01:19 AM 7/26/2001 +0200, Issac Goldstand wrote: [snipped] I see what you mean. I'm not dealing with client certs (yet), and I'm thinking that when the system that I'm testing now goes production, it'll be a front-end SSL, back-end non-SSL sorta deal... But that won't work for now due to other security issues on the developments boxes... [snipped] I understand that. It's just not doable for this... In actuality, the back-end server now is not REALLY back-end... The mod_perl server is _behind_ that, so I'm really doing what you're suggesting already :) However, information must still get to this middle-level server, and the top level server certainly can't be trusted to decode sensitive information... Considering this issue, it seems that what might help you more is a VPN. Have you tried using SSH port forwarding for the time being? And just allow the SSL stuff to go from your external web server directly through an SSH vpn link to the back-end (your true front end) server. Later, Gunther
Re: Not embedding SQL in perl (was RE: [OT] Inspired by closing comments from the UBB thread.)
At 02:44 PM 8/1/2001 -0700, Jeffrey W. Baker wrote: On Thu, 2 Aug 2001, Gunther Birznieks wrote: When you've had your fill of wrestling over mySQL vs PostGres and stored procs versus inline SQL (I know I have long ago) You guys should definitely read the following: http://www.ambysoft.com/persistenceLayer.html One of my current coworkers turned me on to this. I have found it to be one of the best series of articles related towards what it takes to abstract database away from your object layer and the various levels at which it makes sense to do so. You may find the design a little complex, but Scott pretty explicitly states that this is what is necessary for a *large* system. You can always go down a less complex path by choice if you feel your programs aren't complex enough to need the full Persistence Layer structure he advocates. I've worked with Scott Ambler, and I could record everything Scott Ambler knows about actually devleloping large systems on the head of a pin, using a magic marker. That guy is a hopeless academic without the slightest clue of how to actually make software happen. I suppose I can't comment on your opinion as I do not personally know him. But I find his statements to be worthy (as explained further below) regardless of what you say about his real-world knowledge. So I can only imagine that he has taken in many comments from users over the years and made up his articles based on feedback since I think this one is particular is reasonable. Although I've never had to implement all 6 or so object abstractions in the ultimate persistence layer he recommends. :) Here's the brutal truth about persistance abstractions using an RDBMS backing store. At some point, your DBA is going to come up to you and tell you that you code is too slow. You need to rewrite some SQL queries to use a different index, or some sorting hints, or whatever. You will realize that you need to pass some extra information down through your abstraction layers to make it all happen. After that happens twice or thrice, you will slowly come to realize that your abstraction is really no abstraction at all: every time the schema changes, the top level interface needs to change as well. I can't say that I agree. It depends on what you are coding for. Are you coding for performance or are you coding for getting a product out there that is easy to maintain? In many cases, these two requirements are quite at odds. This thread was originally sparked by someone getting annoyed that SQL was embedded throughout the code and finding it hard to grasp how to deal with this. While it's true that the best performance comes from hand-coding the SQL, and if you hand-code the SQL, it should arguably be close to the section of code that requires this SQL, not all programs require this. In fact, very few in my experience. Those that have required speed have required it for a small subset of operations in a larger project. I strongly believe many apps can get away without having SQL embedded. I've been doing it for the last several years and definitely coding and maintenance time improves with some persistence layer abstraction. But yes, you run the risk of having to go back and code a SQL statement or two, and you run the risk of somewhat lower performance, but as Scott mentions in his article, these should be the well-documented exception, not the rule. Nick Tonkin posted a very clear and well written post a few minutes ago about embedding SQL close to the code which may demonstrate the opposite of what I am trying to say. But on the other hand, I could understand that a company such as ValueClick really have to make sure their databases and the SQL that accesses them are completely tweaked. So I think given speed requirements, making a HERE document and using other clean-coding techniques to keep the SQL close to the code that needs it is quite reasonable. However, in my experience... Of the things that are harder to duplicate in a persistence layer to one degree or another... Not all applications require transactions Not all applications require aggregation beyond count Not all applications require blinding speed (just decent speed) Not all applications require joins Not all applications require unions Not all applications require subselects And even if you would argue that taking into account a union of probabilities an application may need at least one of the above, I have found it simply is not true. Usually when an application has a fairly complex data model then they need more than one of the above and that's when you have to move to SQL. In other words, if the probability that an app needs each of the features above is 5%, then rather than the union of the probabilities being 5 + 5 + 5 + 5 + 5 + 5, it is really more like 8% where the majority of the 5% is really in applications that needs more than one of the above advanced SQL list
Re: require v.s. do in modperl
For what you are trying to do, you should turn it into a module. Sorry for the short post, I've gotta split... Although it's not user friendly, my more constructive hint is to type perldoc perlmod to get a quick tutorial on writing a module. At 06:56 PM 8/1/2001 -0400, Philip Mak wrote: I have a CGI application where I do: require 'db.pl'; where db.pl defines some functions and variables related to connecting to the database, and then executes C$dbh = DBI-connect(...). I tried to convert this application to modperl, but I ran into the problem that require did not execute db.pl again the second time I called the script, so that the C$dbh = DBI-connect(...) line was not executed. I can get around this by changing Crequire to Cdo, but is that the correct way of doing things? It seems a waste to redefine all the subroutines and variables again. But I do need it to reinitialize $dbh when Crequire 'db.pl'; is called. What should I do? __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: require v.s. do in modperl
At 07:16 PM 8/1/2001 -0400, Perrin Harkins wrote: I have a CGI application where I do: require 'db.pl'; where db.pl defines some functions and variables related to connecting to the database, and then executes C$dbh = DBI-connect(...). snip I can get around this by changing Crequire to Cdo, but is that the correct way of doing things? No. Put the connect stuff in a subroutine and call it from your application. Things in the main section of a required file are only supposed to run once. I am not sure, but I don't think connect() is only supposed to run once especially with Apache::DBI?
Re: require v.s. do in modperl
At 07:18 PM 8/1/2001 -0700, Nick Tonkin wrote:
On Wed, 1 Aug 2001, Philip Mak wrote:
I have a CGI application where I do:
require 'db.pl';
where db.pl defines some functions and variables related to connecting to
the database, and then executes C$dbh = DBI-connect(...).
I tried to convert this application to modperl, but I ran into the problem
that require did not execute db.pl again the second time I called the
script, so that the C$dbh = DBI-connect(...) line was not executed.
I can get around this by changing Crequire to Cdo, but is that the
correct way of doing things? It seems a waste to redefine all the
subroutines and variables again. But I do need it to reinitialize $dbh
when Crequire 'db.pl'; is called.
What should I do?
One of the things you should do that I have not yet seen mentioned is
look into using Apache::DBI so you don't have it reinitialize $dbh on
every request.
If you do have multiple DBs in your application you can still used cached
database handles; just name them differently.
But you should still call $dbh = connect() on every request so that
Apache::DBI's magic can truly work??
Otherwise ping tests and other such stuff will not work and you may as well
not use Apache::DBI at all and just use BEGIN { $dbh ||= connect() } which
of course, is probably not working well.
Re: Apache::DBI in startup.pl generating error
Alternatively, you can remove use Apache; from Apache::DBI and then you can test it perflectly fine from the command-line, you just won't be able to use connect_on_init() which is the only reason Apache::DBI seems to load Apache.pm (Apache.pm is causing your problem not Apache::DBI). At 10:20 PM 8/2/2001 +0800, Stas Bekman wrote: On Thu, 2 Aug 2001 [EMAIL PROTECTED] wrote: Thanks to all (esp Stas) for helping me with the 'make test' error involving CGI.pm. Here is the next issue: use Apache::DBI (); When I run perl -c startup.pl, I get the following error. I get NO error when I comment out the 'use Apache::DBI' line: Can't locate object method module via package Apache at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 202. BEGIN failed--compilation aborted at startup.pl line 8. Is there an earlier version of Apache::DBI I should be using (like the CGI.pm error)? It's not a problem. Apache::DBI expects mod_perl env, and hence you cannot test it from the command line. I suppose that you don't have a problem to start the server with Apache::DBI loaded. It's documented somewhere is the guide too. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
RE: Apache::DBI in startup.pl generating error
to
understand how this can be considered portable. But if you mean portable
from system to system, well, last I heard, ActiveState hadn't quite gotten
signals or sockets mastered, but I'm pretty certain the have the %ENV
emulation worked out.
But thirdly, I consider it a convenience to be able to test a script for
syntax errors before attempting to -HUP my webserver to see if it works or
not. perl -wc is done almost before I register the cursor moving. apache
restarts take me at least a minute. It's not about the request cycle, it's
about the DEBUG cycle. Since I didn't write Apache::DBI, but I have
reasonable confidence in the guy who did, it doesn't hurt my feelings to
defer initializing it until I've finished modifying startup.pl for other
reasons. Which means I can make a change, switch windows, and perl -wc and
get a syntax check, instead of an Apache error on Apache::AuthDBI, in under
10 seconds. Or even perl -w (even tho I run w/ -w in the shebang line and
PerlWarn On) and see debug output I'm working with.
For the record, I also consider it cheesy to have to check $ENV{MOD_PERL}
but to my knowledge, the Apache $s object isn't passed to startup.pl, and
setting an environment variable is significantly cheaper than creating a
perl object in terms of C code and devel/debug time. Remember, the E in
perl is for Eclectic. :-)
Idioms are there for a reason: They do well in shorthand a required task.
Even if there are other, longer ways to do the same thing. TIMTOWTDI. The
way I ought to program is in the way that makes perfect sense when one
understands all of the pieces, and document the hell out of it so that
people behind me who don't understand can at least follow the requirements
list. ESPECIALLY when the person behind me is me, 6 months later.
/rant
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Re: odd behavior with Cache::Cache
At 05:44 PM 8/5/2001 -0400, Perrin Harkins wrote: on 8/4/01 1:34 PM, brian moseley at [EMAIL PROTECTED] wrote: also, has there been any thought given to locking cached items? when i'm using a shared cache with multiprocess apache, the opportunity exists for multiple requests to access a single session simultaneously, which can lead to races. which i'm happy to ignore for now but would be nice to eventually prevent. Gunther's Extropia stuff includes optional support for sessions that lock in the way you're describing, but I've never seen any other session implementation that did it this way. It seems that the session pattern is generally used for transient data where last-save-wins is fine as long as the integrity of the data is protected during the actual writes. If you need fancier locking, you could try ripping the lock stuff out of Apache::Session. - Perrin My impression was that the locking in Apache::Session is a one-time lock so it just fixes data integrity issues. So I am not sure if it is fancier than Cache::Cache unless Cache::Cache has no locking at all (or no concept of lock choice). I was really interested in abstracting the locking API for Extropia::Session because it was an interesting challenge and frankly at the time I *thought* that Apache::Session did it, so I wanted to match it. In addition, the motivation for Extropia::Session was to match the Java Servlet Session spec so I wanted to make sure that whatever protections were provided by Java, I would have in Perl multiprocessing environment. The latter being fairly difficult to emulate exactly. In the end, I don't think I have actually written any applications that would cause two session updates to occur at the same time, so it might have been overkill. I am lately thinking of session as a means to store very transient stuff but then real persistent application data such as cart data from a web store should be stored in a real data storage with real multi-user locking with the session id as a mere key to that database. I guess it just depends on your scenario. I would be curious to hear about some real world (as opposed to academic) scenarios about it being an issue. Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Augmenting CPAN with P2EE specs, was CPAN polution
At 12:10 PM 8/11/2001 -0400, Stephen Adkins wrote: Hi, At 04:42 PM 8/11/2001 +0200, Elizabeth Mattijsen wrote: At 09:26 AM 8/11/01 -0500, Jim Smith wrote: If we want better QA, I'd propose requiring approval from someone on that list before a module is put anywhere in the heirarchy other than the author's directory instead of only requiring approval for a top-level namespace. Are you aware of the CPANTS initiative? Michael Schwern gave an interesting talk about that at the YAPC::Europe. See e.g. http:[EMAIL PROTECTED]/msg00148.html I like the idea of CPANTS, karma, kwalitee, etc. However, another approach is similar to what J2EE did to Java. There were lots of libraries/packages growing up in Java, and the J2EE spec said these versions of these API's make up a consistent, extensive, useful, architecturally sound platform on which to build applications. What about the concept of a P2EE specification? (P2EE is pronounced pitooey, as in I spit on the notion that Java is the only language for enterprise-capable web application development. It is also pronounced pee-two-ee-ee when managers are around and you want to convince them it is a legit technology for your next project.) (I also note that p2ee.org is not yet taken as a domain.) The idea behind P2EE is not precisely new. Larry Wall addressed it in his State of the Onion speech this year. Basically Perl 6 is the rewrite and he realized the standard distro of modules is really both bloated and too sparse at the same time. So what may make sense is bundling stuff in the same way that Java does. So in Java you have the standard SDK library of class files but you also have the J2EE bundle. We all know that there will never be a single P2EE specification. This is because there will be those who think that one template system/ data persistence layer/XML Library/etc., combination is better than another. However, individual perl gurus could pull together their list of consistent, complementary, and quality API's/modules (and how to use them) in a spec and call it their vision of P2EE. This would be very valuable to those just getting started. They understand that There's More Than One Way To Do It (tmtowtdi), but at least they can survey how various perl gurus have integrated the many different technologies before them and learn at least One Good Way To Do It from each spec. This method of competing P2EE visions * is decentralized and dynamic (not centralized and unchanging), * is merit-centric (P2EE visions will wax and wane based on merit), and * provides a way that individual modules can rise above the crowd. I can envision that module authors would work with the leading P2EE spec authors to ensure that their modules fit into the vision. If the P2EE spec authors like the modules, they get included in that particular spec. In this way individual modules are naturally subjected to a certain form of peer-review in order to qualify for a spec. In return, the visibility of the module is increased because of the spec. If someone doesn't like the existing P2EE specs, they can create their own. Perhaps the various P2EE specs could be supported on CPAN with Bundles. I also think it would be *much* easier to rate/rank P2EE specs than individual modules on CPAN. (i.e. this goal is attainable with a finite amount of effort) Thoughts? Stephen I think this is reasonable. Items for definite inclusion would be POE and SOAP::Lite. I hesitate to include templating systems or application toolkits. Although Caching (Cache::Cache, IPC, etc) could also fall under P2EE I think. Later, Gunther
Re: my() [very off topic]
It is not off topic if you realize that the way Apache::Registry and PerlRun wraps scripts will cause the closures to occur with my. So it's really rude to actually have anew person have to join an entirely new mailing list just because of a problem that mod_perl itself forces the user to deal with and partially is the cause of. It seems to me that he is confused about when the variable will not stay shared or will which is a direct result of using shared programming. Although I don't know what he is confused about because I thought the guide explains it OK? Later, Gunther At 01:37 PM 8/14/2001 -0700, Dave Baker wrote: On Tue, 14 Aug 2001, swade wrote: Much thanks! What do the knowledgable programmers do? Do they my() thier variables, etc at the beginning of thier subroutines? Or do they do it as they come to it? or is it really just personal prefence? This is rather off topic for mod_perl and should (imho) belong on a perl list instead. Can I request any followups be taken to private mail or a more suitable list? Thanks, Dave __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Path Issue mod_perl vs cgi-bin?
At 09:20 AM 8/17/2001 -0500, Purcell, Scott wrote: Hello, I am running Apache w/mod_perl on a NT box. Location = D:/Apache I have created some modules and put the modules in a folder D:/Apache/vb_modules I set my PATH on the NT box to look in D:/Apache/vb_modules and all is good when I use those modules under mod_perl folder. But today, I have the need to write some normal non-mod_perl files so I put a file in cgi-bin D:/Apache/cgi-bin and did a require module; But for some unknown reason, it says it cannot locate my modules? Why is it that the mod_perl folder has no issues and the cgi-bin directory cannot find my modules I have never seen anything like this. Does anyone have any ideas? Is there some config I need to set up in the cgi-bin directory? I don't think so. Note that Apache recognizes the first line of the script and will attempt to resolve Perl in that location. eg #!/usr/bin/perl is resolved by default ( I think ) to c:\usr\bin\perl.exe So you may wish to be truly explicit and use #!c:\perl\bin\perl.exe Instead... (You may have to escape the \ but I forget). Thanks, Scott Purcell __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: [OT] compilers for c Appache modules
I've never done it, but you may want to look for instructions on compiling mod_perl in general on win32. Likely however your mod_perl was compiled is a reasonable way to compile another C module on Apache for Win32. At 10:49 PM 8/19/2001 +1000, Rod Butcher wrote: I know it's offtopic, please direct me to correct data source, can't find it... For the first time I need to compile a module (mod_throttle_access) for Apache on Win32. I have the free Borland 5.5 C++ command line compiler. What settings etc ? (Have the Eagle book, can't find it there). thanks. Rod === This email message may contain the Ebola virus. The sender is not responsible for any death, destruction, reflux or tinitis that may result from reading this message. The sender's lawyer forces him to write this crap. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: [ANNOUNCE] TicketMaster.com sponsors mod_perl development
At 01:28 AM 9/21/2001 +0800, Stas Bekman wrote: If you remember back in the end of April, I've posted to the list an unusual job seek request [1], where I was saying that I want some company to sponsor me to work full time on mod_perl 2.0 development. Believe it or not my unusual request has been answered by Craig McLane from TicketMaster.com (which owns citysearch.com). citysearch.com is a heavy user of mod_perl technology and interested in making sure that mod_perl technology get more and more mature and ensure their business' success. So starting from this September I'm working on mod_perl 2.0 development, a new documentation project (which you are welcome to join) and doing mod_perl advocacy through teaching at the conferences and other ways. You can reach your goals. I'm living proof. beefcake. BEEFCAKE!! -- Eric Cartman Congratulations to Stas! Currently the contract is for one year. But if everything goes well, and mod_perl 2.0 rocks the world even better than 1.x did we will see more support and sponsoring from TicketMaster. This email's purpose: - is to set a precedent for other business to sponsor mod_perl and related technologies. There are at least a few excellent developers that I know will jump on the opportunity of being able to do what they love full time. - is to set a precedent for other developers to seek what they really want and read less stories about hi-tech recession, since good developers are always in demand. Therefore I hope that this email will encourage you to do that. Notes: [1] http://forum.swarthmore.edu/epigone/modperl/runvesay _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: [VOT] What hourly rate to charge for programming?
Hey guys..MASSIVELY OFF TOPIC!! :( :( :( At 12:24 AM 10/3/2001 -0400, Michael Bacarella wrote: I've had about two years of experience with perl, and one year of experience with mod_perl and MySQL. I've been doing contract programming jobs for people and charged by the hour. The rate I currently charge them ($40) was kind of chosen randomly. I'd like to find out if this figure is too high/too low. Does anyone here have any experiences to share? Contract programming is entirely different from salaried work. Assuming you live in the United States and are charging US dollars, Consider: Taxes (including an additional self-employment tax). Insurance (health, general liability, and possibly others) (Home) Office Expenses -- stuff you use to generate invoices, stuff you use to do your actual work if done in your home, rent, etc. Continued education -- consultants are expected to be experts. Greater risk. You generally will also never work as much as you'd like to. Your clients also get to wash their hands of you completely. Your expenses are a direct tax writeoff, rather than an additional accounting headache. After deducting all of the above, a $40/hr rate starts looking more like an $18/hr rate, and maybe even less. Consultants don't _just_ bill $100/hr because they're scam artists. :) It depends on your location of course. I notice that Michael is in Manhattan which is a pretty expensive salary area of the USA. And it also depends on how long you are on a contract -- 6 months? A year at a time? or just a week or two to solve a specialized problem? You're charging effectively half of what a salaried perl/mysql hacker costs. Humility is a valuable business trait, but I'm positive you're worth more than you're charging. Maybe.
Re: Excellent article on Apache/mod_perl at eToys
Yeah we really enjoyed it over here. I think it's really excellent to get great advocacy articles about Perl and surrounding products (mod_perl, TT, etc) powering real businesses with real high powered needs out there like this one. :) At 04:40 PM 10/19/2001, Greg Cope wrote: Andrew Ho wrote: Hello, I checked the list archives and it didn't look like this had been posted yet. For those of you who haven't seen it yet... a great read on perl.com about the Apache/mod_perl setup at eToys, co-authored by our own mod_perl regular contributer Perrin Harkins. http://www.perl.com/pub/a/2001/10/17/etoys.html Yup, this is an excellent read. Thanks Perrin. Greg __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
RE: Excellent article on Apache/mod_perl at eToys
At 09:14 AM 10/23/2001, Robert Koberg wrote: For comparions, a nice aspect of j2ee applications IMHO is the application server tends to be more general. ie. the application server is not just the web server (as it is with mod_perl). I've found j2ee features such as message beans, queues and such especially useful for back-end work. For these reasons, I personally don't buy the argument that mod_perl makes an effective application server for a good sized task (your mileage will vary no doubt ;). What is stopping you from using both, if you want? It's generally quite tough to convince management that maintaining two sets of knowledge -- Java and Perl is cost effective. I suppose it depends on the size of the organization but consolidation of standards in an organization is an age-old thing (eg move all servers to NT, move everyone to Java, etc...) Whether this actually saves costs is a bit of an arguement probably not best for this mailing list. However, I would have to say that I feel like coding middleware in Java is easier and more standardized, and well documented. But I feel like coding front-end web applications is much easier in Perl where the workflow bits change all the time. For this, I like using SOAP on the backend Java server and SOAP on the front-end Perl. YMMV. And I don't know that many organizations which will allow such a heterogeneous environment unless a vendor installs it as a turnkey solution and is willing to deal with all the support. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Excellent article on Apache/mod_perl at eToys
At 08:46 PM 10/23/2001, Rob Nagler wrote: is easier and more standardized, and well documented. But I feel like coding front-end web applications is much easier in Perl where the workflow bits change all the time. For this, I like using SOAP on the backend Java server and SOAP on the front-end Perl. I don't quite understand the difference between worflow in the front-end and workflow in the back-end. They both change. The danger of making one part of the system easier to change is that people tend to cheat. They won't put the business logic in the back-end if it takes twice as long. Yes, people can cheat. But generally the workflow that is most likely to change is the UI based workflow. UI isn't just about templates, it's a lot about how you go from one screen to the next, or not. Actually business logic is a bit of a misnomer because there is plenty of business logic in the front-end from your choice of fields to the javascript to the UI workflow. To me, the major issue in Perl vs Java is dynamic vs static typing. Building large scale systems in Perl is much like building them in Smalltalk or Lisp. It takes a certain mindset. The lack of compiled interfaces means you need much more discipline (e.g. unit testing). The payoff is big with Perl, because you can refactor more easily and quickly than in Java. I don't think refactoring in Perl is necessarily faster. Actually, it can be quite hard to refactor in Perl as well but for the opposite reason. If you do not have a strongly typed system, then when you break apart and rebuild another part of the system, Perl may very well not complain when a subtle bug comes up because of the fact that it is not strongly typed. Whereas Java will complain quite often and usually early with compile time checking. Compile time checking can definitely be a friend of yours especially when dealing with large systems. But it's also a friend that's judgemental (strongly typed) so he's a pain to drag along to a party In practice, I still think using a good framework, it's about as long to develop in Perl as it is in Java for a medium sized system. My only beef I have with Java and I still have it is that the debugging support is simply atrocious for web apps. Perl has many more debugging utilities and allows much greater introspection. When I develop in Java, the only reason it takes me about 20% longer is that I am restarting the server much more often than I do in Perl. The libraries aren't much an issue. A good example is SOAP. SOAP is middleware. It is standardized, documented, and the rest of it. You like it for connecting Perl to Java, but why can't it be the other way around? If it can be the other way around, why aren't Perl and Java equally adapted to building middleware applications? Java's support for multi-threading makes writing servers feel fairly trivial with no jumping through IPC::Shared memory stuff hoops to get shared memory caches and the like.. you just synchronize on global data structures. Arguably, an overuse of threads has problems in itself, but in general, I think it is easier. It is also easier to find programmers who know how to code middleware that do Java and harder to find people who have coded middleware that are Perl programmers... so maybe the language would support it, but there is also a personnel issue. Later, Gunther
Re: Excellent article on Apache/mod_perl at eToys
At 09:45 PM 10/23/2001, Perrin Harkins wrote: Matt Sergeant wrote: OK, so what are we missing? Based on the comments I've seen here over the years, and some on Slashdot, the thing that seems to worry people the most is the lack of an obvious message queue API in Perl. I've seen plenty of implementations, but there isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. I think it's more than that. It's more of a general all around 'feeling' as I've said before. It's about people and it's about the standards. The thing about Enterprise applications is that there are many components to what enterprise means J2EE compromises a lot of standards and frameworks all in one and to read the books about them all would take several weeks at least. But at least I know that when I read a book on EJB, I know this is the plan and it's stable etc... whereas someone's particular idea of a transaction engine in Perl is just someone's idea of a transaction engine in Perl. It may be a good idea, but it's really quite scary to build a large system around something that may not have a lot of success stories around it. This is why Perrin's article is so good. Because it starts getting more high profile success stories out there. There really are otherwise not that many about Perl when compared to Java. And even then, let's also consider the programming base. When I advertise for Perl programmers, they generally just know how to do Web apps and it's pulling teeth to even get OO and Mod_perl capability. It has to be taught after such programmers are brought in. But with Java, it's quite rare to find a Java programmer that hasn't programmed at least their own minimal RMI server before. I have little doubt that this is because of the sheer amount of documentation for making an RMI server plus the fact that it is a true standard so people feel comfortable that it is supported in a large community. Remember that my email said, I feel better about coding middleware in Java than in Perl. Just as I feel better about coding front-end in Perl. This is a feeling and isn't necessarily something that can be quantified -- it is also about perception which is something that cannot be ignored. And part of it is about soft issues like knowing that I can find Java programmers at a dime a dozen who have done middleware coding before in Java. I think more success stories would help. I also think official endorsement by key members of the Perl community (eg Larry) would help certain projects. ie I believe SOAP::Lite is now the defacto standard SOAP Library for Perl that people would recommend anyone to use no? So why is it still SOAP::Lite and not moved and advocated into the SOAP namespace where it belongs and make it the defacto standard SOAP engine for Perl if it's proven itself? Of course, choice is part of what makes Perl fun. But fun isn't for everyone. eg when it comes to such niche libraries as middleware tools, it's not so fun to have choices if none of the choices are very easy to evaluate. It's much nicer for a programmer to be able to reliably choose a tool they feel is backed by a strong community beyond just the immediate few people who may have done X middleware for one project or group of projects for one company. I really would like to see a generally endorsed P2EE project which includes SOAP::Lite as an interoperable webservices engine, a messaging engine, and transaction engine. Authentication engine and Session engine would be quite useful to include as well. Oh and Moseley's (sp?) servlets in Perl project would be a cool one to include as well. That would make it compete pretty much head to head with J2EE. And then success stories on top of P2EE. Later, Gunther
Re: Excellent article on Apache/mod_perl at eToys
At 10:36 PM 10/23/2001, Leon Brocard wrote: Perrin Harkins sent the following bits through the ether: Perhaps a port of JMS is in order. Interestingly, I've been thinking along the same lines. Spread (http://www.spread.org/) can be used for the publish/subscribe messaging domain but queueing seems to be important too. Straying a bit offtopic perhaps, but I wonder what would be involved... One thing that would be interesting to me is an engine that can provide real time pricing feeds. It seems to me that jabber (chat engine) is actually a lot more powerful than being about chatting. Some applications are lonely and want instant messaging too. :) Queuing is important but for different reasons and usually different applications eg if your circuits are global. eg a London broker makes a transaction destined for Singapore, but has to go via Hong Kong and the London/HongKong circuit is only up every 5 minutes... Although this is not dissimilar to the resilience of a message delivered via SMTP relays.
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 03:38 AM 10/24/2001, Stephen Adkins wrote: At 02:28 PM 10/23/2001 -0400, Perrin Harkins wrote: Stephen Adkins wrote: If no one suggests an appropriate list, I propose starting a p2ee group Can I just say that P2EE is a horrible, horrible name? It includes the Java version number (when is J3EE coming out?), as well as Sun's desperate attempt to make it sound like something you buy (Edition) rather than simply a collection of APIs. Something simple, like Perl Enterprise Project or Perl Enterprise APIs makes more sense to me. Hi, Several of you have made the same good point. And now the naming flame war has already begun... ;-) Unless there is violent opposition, the name will be Perl Enterprise Framework I would rather name it after the outcome (Framework) than the process (Project). The mailing list will be [EMAIL PROTECTED] (preferred) or [EMAIL PROTECTED] (in case Nathan already has it set up) If this seems reasonable, let's not flood the list with ok with me messages or how about 'foo'? messages. Stephen I think this name and mailing list is excellent and much better than P2EE. The mere fact that there is an endorsed perl.org mailing list for people who wish to ask about enterprise issues (even without a specific standard) is a huge step further in terms of making people aware that Perl CAN BE used for the enterprise. That is, there is a definite perception difference between [EMAIL PROTECTED] and [EMAIL PROTECTED] [EMAIL PROTECTED] has a perception of being endorsed as a place for a standard rather than just a single couple of people's ideas on sourceforge.com (of which there are thousands) and is likely to get more attention.
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
One important thing THERE IS ALREADY A P5EE MAILING LIST GUYS!! :) So basically if you want to add your feedback, go there! It's already done but it's not too late to add feedback. :) email ... [EMAIL PROTECTED] At 08:36 AM 10/29/2001, Medi Montaseri wrote: Similarly, this concept of Enterprise is a bugus idea ... from a pure computer science point of view, there is no such thing as an Enterprise. This is all Microsoft's branding trying to associate themselves with something big, and Sun is stupidly following it A pure computer science point of view... Well, very few things exist from a pure computer science point of view because it's based on low level algorithms typically. However, that does not mean models that encapsulate the complexity of all the algorithms put together in certain ways do not have or add value. The concept of the enterprise is a very real model of interpreting the world of IT and how to distinguish between a localized, single-protocol systems and an enterprise system. Enterprise being a Microsoft Branding term? I don't think believe that it came before Sun. Sun and Microsoft are not branding themselves the same way. And I believe that the term enterprise has been around for quite some years independent of Microsoft. However, because of the Java and Sun branding of J2EE, it is important that Perl and other languages come together to say how they fit the enterprise as well. Why is this important? Credibility. While it's true that many businesses do not require enterprise solutions, a business can feel more comfortable adopting a solution if they know that it can grow with them. For example, if I were to download a public domain web store, I would much prefer knowing that the ecommerce solution were used by Amazon.com because then I'd know that if my ReeferOnline store were to take off in Columbia, that it would scale and I wouldn't have to look for an alternative solution. Also, the fact that a larger corporation can use the application means that they've worked out security and other issues better than I, a small IT arm of a huge Drug Overlord, can afford the time and effort to check out. While not everyone may need these additional reassurances from a marketing point of view, the majority of the world does. My vote is to come up with something more pure than trendy like Enterprise. My vote is that anyone who doesn't like a name should be the first person to come up with an alternative idea rather than just negating it and asking for others to come up with the hard work of coming up with something different. :) Anyway, please do visit the P5EE list. There is also an archive of past posts so you can play catch up from the last week. http://archive.develooper.com/p5ee%40perl.org/
Re: [OT] Re: Seeking Legal help
At 01:34 AM 11/23/2001, Mark Maunder wrote: Matt Sergeant wrote: Step three: Once you've given them 90 days after date of invoice, get a solicitor (not a barrister) to draft a threatening letter. It'll cost you about $100. I'm afraid you'll have to give them another 30 days at this point. Step four: Get a lawyer. Sue. $25,000 is not to be sniffed at. What many small companies and one man operations dont realise is that debt collecting is an art. Also, some large companies (large banks in particular) have a policy of 'If you want to do business with us, we take 60 days to pay. It's all about keeping the cashflow on their side. It depends on the company, I think most take a long time to pay the first time because it's the first time you are being entered into their computer systems, contracts get signed off completely etc.. Of the large companies (banks included) we work with this is normally the case (a 60-100 day to get paid the first time), but subsequent times are usually quite easy for us as most of our large customers repeat back to us and we are already in their system for getting paid by their accounts payable department. Of course, there are exceptions to the rules, but I don't see large companies just arbitrarily trying to pull a longer cycle. At the least, they do usually have to wait for the accounts payable cycle and cutting an out of cycle check is a pain in the ass, but that comes sooner than 60 days. I think 60 days etc is reasonable if you are on a 1M-2M contract, but if your contract is a few hundred K over a year, it hardly will make that much of a collective cash flow dent to warrant it being worth their policy. By the way, if you are really working for a bank and cashflow is an issue for you in 60 days you can also ask the bank what business banking services they offer. One popular service with small businesses who have large companies working for them is invoice factoring which allows you to sell your invoice (if your company passes a credit check) to the bank for something like 80% of the face value of the account and then when the bank collects the invoice you get the rest minus interest and commissions. It's unlikely that they would grant the same credit with a 1-man company though. And I think they don't like dealing with service businesses. It's usually more for dealing with suppliers with real inventory where the main thing that can go wrong with an invoice is a pricing dispute over a line item of widgets I suspect. The other thing is that if you do a contract, build in billing cycles. 20-30% up front on a fixed fee contract is not unreasonable. Of course, you may need to commence work anyway before getting it if they are a large company that is having trouble getting you in their system, but that is the risk. But in any case, you can soon usually figure out whether they are going ot be paying your schedule or not. If you are just a normal hours-based contractor, then it's a bit more like getting a salary and so I think it is much harder to argue to be paid up front. I did some work for a certain Linux distributor in the UK recently and they took 100 days to pay after much harrasment. If you're small you have to be tough - put the geek aside and become that vicious old lady that is usually hired to badger late payers. The same all over the world. ;) Later, Gunther
Re: [OT] What hourly rate to charge for programming?
C'mon guys remember to add OT to your off topic messages! It's not that hard. :) At 05:14 PM 10/10/2001, [EMAIL PROTECTED] wrote: I'd like to know where I can get paid more than AU$10/hour (US$4.90 to US$5 per hour) for my mod_perl programming... You guys in America get $100US per hour?! My god, I'm in the wrong country... America is richer than Australia. Work is scarce in Australia and poorly paid in most cases compared to America. If I could get US$20 per hour for programming work I would be overjoyed with that! I'm not experienced in mod_perl commercially so I doubt I would get more than that, but I think US$20 per hour is reasonable for quality labor nontheless. I need to work from home. Anybody got any suggestions? I have looked on Yahoo for work from home jobs and they seem to be crooks. I never get any responses. There's part of your problem. Few people trust telecommuters they don't know unless the job is fairly clear. I know I don't. I have telecommuters working for us on occasion but I know them or I trust them based on knowing them through a third party. You're lucky you get what you get and the price you get it. You're cutting yourself down of opportunities by having to work at home. I don't mean to be so frank about it. But really... this is a huge factor. It's a great luxury to work at home but it rarely works out unless you are really highly motivated or highly disciplined. Some people are like that, unfortunately this is not the majority of people so adding the project management overhead on behalf of the client means having to drop the hourly wage to the work-at-home consultant.
Re: Catching user-presses-stop early
Would sending a null byte work with a reverse proxy method of mod_perl if
the reverse proxy caches and doesn't deliver the data right away? I don't
know if there is a way to control this or what the behavior is.
As an aside, why not just send whitespace instead of a nullbyte? It's
supposed to be ignored anyway unless you are sending binary data.
At 06:35 AM 10/13/2001, Jeremy Howard wrote:
Our site is suddenly getting to the point where resource constraints are
becoming an issue for the first time. So, apologies in advance if I have
lots of optimization-related questions over the next couple of weeks...
One thing I would like to catch is the related problems of:
- Users pressing stop in the middle of a long process
- Users double-clicking rather than single-clicking links
(resulting in 2 processes handling the request)
I've read the 'user-pressed-stop' bit of the Guide (thanks Stas!) and
although I think I understand the issues now, I'm looking for practical
advice on approaches people use. I'm thinking that I should try writing a
null byte to the client:
- At the beginning of the handler
- Every few iterations of potentially long loops
- Before creating large files to send to the client.
If I do this then Apache should receive the signal that the client has gone
away, and should terminate the process happily (as long as I clean up
properly, of course).
So, does this sound like the right approach? Any way to simplify this to
avoid explicitly adding print-a-null-byte lines to every loop? I'm wondering
whether it's possible to add an alarm() and SIG{ALRM} handler or something
like that, which sends a null byte every second or 2. Anyone using something
like this successfully? Any potential problems from sending a null byte to a
client?
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Re: Mod_perl component based architecture
At 11:13 PM 10/16/01, Dominique Quatravaux wrote: also does modperl support object oriented programming? Well yes it does indeed (see any good book on Perl, such as «advanced Perl programming» from O'Reilly). As for the remaining of the question, I've been wondering for myself if there is a MVC (model-view-controller) framework for WWW publishing in Perl ? I gather there exist quite a few for Java, but I couldn't find anything significant under Perl. Our eXtropia toolkit is just about the only one out there that caters to all CGI environments with MVC architecture (action objects and action manager for controller, normal DB objects for model, and template toolkit for view)... If you go to http://www.extropia.com/ you can download any Perl WebDB app, WebCal, or WebBBS to see an example. We are still in a mode where we are distributing apps built around the framework rather than the framework itself but you can get the idea. WebDB in particular has a lot of documentation itself for free. If you are really interested in toolkit docs, we have an 800 page book out by McGraw-Hill whose later half 400 pages discusses in raw detail the architecture of the toolkit itself and how all the pieces fit together. One of the sad things is that the intelligent people on this list tend to have their head a bit in the ground when it comes to alternative environments other than mod_perl. mod_perl's a great tool but there's a lot of other Perl environments out there not the least of which is just plain old CGI. This is why our toolkit specifically caters to all. The other thing is that many (although not all) Perl people tend to have their head in the ground related to dealing with other environments such as Java. Our toolkit also plugs into Java environments. For example, we have a completely interoperaple Perl - Java persistence layer (via SOAP) if you wish to use a Java driver for a Perl front-end. We also spent considerable time porting our toolkit and several apps to Java MVC framework so we have Java Servlet/JSP equivalents of everything. Yet another thing is that many Perl people also have their head in the ground about Win32 compatibility. We've strived to make sure our entire toolkit will work reasonably well on Win98 and Win2000. A toolkit that only works on mod_perl will by definition not work well on Win2000 except as a toy because Win32 mod_perl is a single blocking thread. Great for development, not so great for production (unless the site is really small). I would venture to say that some of the mod_perl-only toolkits have some cases of being better designed than ours, but they are mostly mod_perl only. In fact, I don't know if I know any other toolkits than ours that are not mod_perl only of the ones that were advertised on the list. Of course, this may be what you are looking for. But since you mentioned Perl MVC and not specifically mod_perl-only MVC, I figured I would jump in and mention the alternative since we are much more open to alternative environments and not being closed in to just mod_perl. Later, Gunther
Re: Mod_perl component based architecture
At 01:28 PM 10/17/01, Ilya Martynov wrote: On Tue, 16 Oct 2001 22:07:47 -0500 (CDT), Dave Rolsky [EMAIL PROTECTED] said: DR On Wed, 17 Oct 2001, Gunther Birznieks wrote: I would venture to say that some of the mod_perl-only toolkits have some cases of being better designed than ours, but they are mostly mod_perl only. In fact, I don't know if I know any other toolkits than ours that are not mod_perl only of the ones that were advertised on the list. DR I don't know if Mason counts as a full toolkit (its not really an app DR server) but you can certainly run Mason as a vanilla CGI, and if you can DR do that I'm sure you can run it in FastCGI and whatnot. Moreover I have seen it being used in command line tool which generates static HTML pages from a set of templates. Well so is Template Toolkit but it's still basically a content management/template engine not really an application framework. It's possible that Mason has applications written in Mason, just as you could write applications in ActiveServerPage or Cold Fusion pages, but that doesn't make ASP or Cold Fusion an Application Framework either. Or at least not a balanced MVC one. Open Interact, Smart Worker, and ours do not handle templating at all. We integrate with other packages to do that sort of management. We have frameworks that handle application logic in a fairly consistent way and this is what is meant by app framework (as opposed to template framework). Of course, I am not saying that the line isn't fuzzy especially if the template engine is quite powerful (as is the case with Mason or AxKit). But there is a line nonetheless, no?? Later, Gunther
Re: transient object data
At 10:19 PM 12/22/2001, DeWitt Clinton wrote: On Sat, Dec 22, 2001 at 06:11:33AM -0800, brian moseley wrote: doesn't it seem like there should be a way to denote object data as transient so that it doesn't get serialized by Storable, etc? I'd love that as well. For example, when persisting Cache::Object instances I manually strip out transient (in this case, it is re-creatable) data such as the name of the key and the size of the object, in order to save space in storage. Sounds like Perl 6 needs a generic notion of Serializable. I think that is fine for Perl 6, but what do we do now? I think implementation wise it seems that there are several ways to serialize objects in Perl. So the natural thing to do is come up with some meta data standard that perhaps all the various authors (Data::Dumper, Storable, etc) like and use efficiently. I think an object of type Transient seems OK. Then, to make an element of a Perl data structure transient, you would add another element to that data structure of type Transient. If the data structure is an array, then the value of the Transient object should be an array of index numbers related to values that are supposed to be Transient. If the data structure is a hash, then the value of the Transient object should be an array of key names related to the values that are supposed to be Transient. If the data structure is an object, you would alternatively look and see if @ISA Transient, if it is a transient (through multiple inheritence) then that object type would never get serialized. Would this cover most general cases? So should this be a thread on p5ee or on mod_perl? :) Later, Gunther
Re: Cache::Cache locking
At 10:55 PM 12/22/2001, brian moseley wrote: Apache::Singleton::Server got me thinking about Cache::Cache and locking again. if i'm going to have a server-global object, i am going to need to protect against multiple processes updating it simultaneously, right? we've already talked about this in regards to sessions. most folks seem to feel that last one wins is sufficient for session data. but what about for objects for which this policy is not good enough? if locking is necessary in some instances, even if we can only contrive theoretical examples right now, how might it be done in a performant way, especially for objects that can be modified multiple times while handling a single request? seems like if you synchronized write access to the object and caused each process to update its local copy after each modification, you'd have a hell of a lot of serialization and deserialization going on in each request. thoughts? Well, I think it depends on the situation. In Extropia::Session what we did was set up policies. The default policy is similar to Apache::Session. But we allow stronger policies if another application requiring more stringent care on the session data shares the user session handle and underlying data store. We ended up separating the concept into two seperate policies: a cache policy and a lock policy. Cache policies are things like no cache, cache reads, cache reads and writes (so nothing gets written until the object is destroyed or flushed manually). Lock policies include no locking (last wins), data store (the whole cache is locked because attributes may depend on each other), and attribute level locking (integrity is only maintained on the attribute write level). These policies effect a general policy of how Extropia::Session works. I think there are more sophisticated ways of doing an API than an arbitrary policy of course. In some cases, locking is something that should be settable directly. For example, I mentioned some attributes may depend on each other. For example, let's say a session stores an attribute indicating your savings account and another indicating your checking account. Obviously to perform a funds transfer within your session you'd want to wrap both attribute changes inside of a lock. Of course, this sort of lock can be separate from the session cache. But ideally in order to interact well with previously set session policies the locking that is automatic should be similar to the locking that is explicit. I think if I had to do it over, I would probably not have implemented my own Session and reused one of the newer caching mechanisms. One of the reasons I didn't go with Apache::Session is that I needed more sophistication than Apache::Session provided but I did like Apache::Session enough that we wrap around it and provide the extra session features I wanted. Later, Gunther
Re: transient object data
At 03:33 PM 12/23/2001, brian moseley wrote: On Sat, 22 Dec 2001, brian moseley wrote: doesn't it seem like there should be a way to denote object data as transient so that it doesn't get serialized by Storable, etc? dammit, i keep deleting peoples' replies before i am able to reply to them myself. gunther's suggestion was to use multiple inheritance. would it be possible to use an attribute instead? By attribute do you mean an element of the data structure that is blessed in the object? Or do you mean some sort of new attribute you would assign a new Serializable data type (ala something to suggest for Perl 6). Actually I think I was suggesting multiple inheritence as the 3rd mechanism. But I think it is fairly mandatory that the Transient object be an attribute or element of the data structure hash or array. Because not only objects should be serializable with transient elements, but so should general data structures I suspect. This is not so in Java so much, but definitely in Perl with it's more flexible ideas of what constitutes a data structure vs object then serialization needs to be equally flexible I suspect. Of course, this brings us back to the discussion of what a Perl bean would be like and how different it should be from Java. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: Fast template system
At 05:05 AM 12/31/2001, Ryan Thompson wrote: I've looked at TT (and have heard it's praises sung), but it requires Perl 5.6.0, which is, unfortunately, not yet stable on all of the production systems my projects are deployed on. The syntax and features look about right, though... So it is something I might try when 5.6.0 is more widely deployed. When did it switch it's position? I am using a version of TT from a few months ago but on 5.00503 quite nicely.
Re: kylix: rad!
At 06:16 AM 1/14/2002, brian moseley wrote: On Sun, 13 Jan 2002, Sam Tregar wrote: On Sat, 12 Jan 2002, Perrin Harkins wrote: Well, does this product actually have any users to compete for? GUI builders usually don't work for anything but the most trivial websites that could be written in anything and do fine. People seem to come to mod_perl because they need more performance or more control than they can get from CGI. Agree. you know, i think it's this attitude, or a more insidious version of it, that keeps mod_perl from being as ubiquitous as php. it's like having to pledge the frat before you can get the hot chicks. i, for one, would like to see more people getting interested in making it easy for people who don't practice black magic to take advantage of mod_perl. OK, I learned mod_perl, now where are my hot chicks! :) I think a UI tool would help a bit, but it wouldn't necessarily solve the hard part of mod_perl which is the lack of Interpreter cleanup between invocations. PHP and ASP clear their variables at the start so it seems harder for applications to overwrite each other and cause weird subtle bugs. I guess there is PerlRun (but it's not true cleanup) or PerlRestart, but that's really slow To some degree, the nature of mod_perl feels like it makes it harder. A UI would help though especially if it had a debugger that learned when attached to a given httpd process what variables were being preserved and reused over and over again... so you could trace those things down. A point to note... even though we give out free Perl and Java applications, we feel that even our own config files are large and therefore daunting for beginners so we have been doing RD to come up with a web interface to create config files for MVC based web apps. A UI is not what we want because we'd like people to go through the wizard and then be able to download a pre-packaged app. I Think making things easier is always a noble effort but it's not always clear until you try, what is truly easier. 1 size doesn't usually fit all. Many peple like IDEs, many people hate them... Later, Gunther
Re: Single login/sign-on for different web apps?
Of course, the best authentication system for banking I've seen is from UBS. They send you a scratchlist of around 100 numbers. Every time you login you use one of the numbers and cross it off. Very slick. Does that really work in practice? That sounds really annoying. Is this for business banking or for retail? How do they get the next 100 numbers to the user? Do they mail it out when they've used 90? It sounds like it would be less annoying to use certificates and some plug-in token there is going to be that much extra work to deal with a password sheet.
Re: UI Regression Testing
I suppose it depends on what you want out of testing. Frequently, unit testing is OK in simple applications. But in an application whose job it is to communicate with a mainframe or back-end databases, frequently the tests you might perform are based on some previous persistent state of the database. It takes a lot of effort in other words. For example, 2-3 programmers could easily get away (through normal testing) with sharing a database. But generally if you require each programmer to have their own database and their own system completely where they are constantly wiping the state of the database to perform a test suite, this can get time consuming and entails a lot of infrastructural overhead. I've seen some articles that demonstrate doing something with test XML backends to emulate database retrieval results, but these seem quite hard to set up also. I agree that testing is great, but I think it is quite hard in practice. Also, I don't think programmers are good to be the main people to write their own tests. It is OK for programmers to write their own tests but frequently it is the user or a non-technical person who is best at doing the unexpected things that are really were the bug lies. The other annoying thing about programmers writing tests is deciding where to stop. I believe the HTTP level for tests is really good. But I see much unit testing being done on the basis of writing a test class for every class you write. Ugh! That means that any time you refactor you throw away the 2x the coding you did. To some degree, there should be intelligent rules of thumb as to which interfaces tests should be written to because the extreme of writing tests for everything is quite bad. Finally, unit tests do not guarantee an understanding of the specs because the business people generally do not read test code. So all the time spent writing the test AND then writing the program AND ONLY THEN showing it to the users, then you discover it wasn't what the user actually wanted. So 2x the coding time has been invalidated when if the user was shown a prototype BEFORE the testing coding commenced, then the user could have confirmed or denied the basic logic. The same frequently and especially is true for UIs. Later, Gunther
Re: UI Regression Testing
From the description of your scenario, it sounds like you have a long product life cycle etc. I think your testing, especially regression testing and the amount of effort you put into it makes a lot of sense because your software is a long-term investment possibly even a product. I think you can worry about an API not having a test for it, and I do a bit, but I don't lose sleep over it. The reality is many APIs succeed OK without tests and maybe a few grumbles hear and there if and when things break. I've rarely seen a documented API break in such a significant way that either I programmed or used from someone else that I could not easily rectify it or go back to a previous version until it was resolved. ie major API changes usually have a way of being known anyway very quickly. Would API tests for every API in existance solve that? Could be, probably yes. But is it worth all the extra coding time for those tests? I don't think so. Not for all APIs. To each his own I guess. I agree with tests for some things, just not for all things including not all APIs. At 08:59 AM 1/26/2002, Rob Nagler wrote: Gunther Birznieks writes: the database to perform a test suite, this can get time consuming and entails a lot of infrastructural overhead. We haven't found this to be the case. All our database operations are programmed. We install the database software with an RPM, run a program to build the database, and program all schema upgrades. We've had 194 schema upgrades in about two years. unit testing being done on the basis of writing a test class for every class you write. Ugh! That means that any time you refactor you throw away the 2x the coding you did. By definition, refactoring doesn't change observable behavior. You validate refactorings with unit tests. See http://www.refactoring.com To some degree, there should be intelligent rules of thumb as to which interfaces tests should be written to because the extreme of writing tests for everything is quite bad. Again, we haven't seen this. Every time I don't have unit tests, I get nervous. How do I know if I broke something with my change? Finally, unit tests do not guarantee an understanding of the specs because the business people generally do not read test code. So all the time spent writing the test AND then writing the program AND ONLY THEN showing it to the users, then you discover it wasn't what the user actually wanted. So 2x the coding time has been invalidated when if the user was shown a prototype BEFORE the testing coding commenced, then the user could have confirmed or denied the basic logic. Unit tests aren't about specs. They are about APIs. Acceptance tests need to be written by the user or written so the user can understand them. You need both kinds of testing. See http://www.xprogramming.com/xpmag/Reliability.htm Rob __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: New mod_perl Logo
I agree. mod_perl is a technology not a platform. Java is called Java, Servlets are called Servlets, but products on top of the technology (eg app servers) are usually have the name Orwellian Pearlz Factory. If you wanted to use a marketing name, you should have just told them you were using one of the frameworks on top of mod_perl like AxKit or Mason. At 08:59 AM 1/30/2002, Robin Berjon wrote: Hi ct ! On Wednesday 30 January 2002 01:29, Chris Thompson wrote: Well, I'd like to just throw one idea into the mix. It's something that's bugged me for a long time, no better time than the present. mod_perl is a lousy name. There, I've said it. This discussion has occured already. The conclusion was simple: the name won't change. Doug cut the talk saying that he won't change the name, and I must say I agree. That isn't to say your points are invalid, you're concern is justified. The solution here is not to change modperl's name. modperl, in a way, is a low level thing. It's just Perl + Apache. When in need of a convincing name, say I use Foo where Foo is the name of something that runs on top of modperl. I use AxKit, I use FooAppFramework, etc. can sound a lot better. Of course, on top of that you need a good looking website with marketing talk. In any case changing the name alone doesn't help. Website content welcome ;-) -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Paranoids are people, too; they have their own problems. It's easy to criticize, but if everybody hated you, you'd be paranoid too. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: New mod_perl Logo
How could another name look nice on your resume if they don't know what it is ? Why don't you just nickname mod_perl as something else and then put THAT name on your resume if you are so concerned about naming. At 09:36 PM 1/30/2002, Paul Cotter wrote: mod_perl is a lousy name. It is causing me a problem. My potential customers have heard of Perl and Apache, MySql and Postgres, but they dot like the idea of perl modifying the Apache processing. It strikes them as tinkering round with the internals and liable to cause problems 'when we upgrade' or 'move to another platform'. It also does not look good on a resume when you are sending it to someone who has never heard of it. You are never quite sure whether to Wordcap it or not. Give it some other marketting name, even if it keeps its original name in places like this. Anything will do, WebBlast, Insiouxiance, Perlandra, Exsight, Insite, HowtoSite - I really do not mind. Regards - Paul Cotter __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: New mod_perl Logo
At 04:50 PM 1/31/2002, brian moseley wrote: On Wed, 30 Jan 2002, Paul Cotter wrote: Give it some other marketting name, even if it keeps its original name in places like this. didn't you people read perrin's message? do you think this is the first time this topic has been discussed? do you think it's gonna change doug's mind /this/ time? if you can't sell your customers and bosses on mod_perl because of its technological appropriateness, the name of the software is the least of your problems. I was thinking if we renamed mod_perl as George Bush it would do quite well in the political polls. Might even be elected for president. And then we'd rule the country!!
Re: [ANNOUNCE] The New mod_perl logo - results now in...
At 10:46 PM 3/15/2002, John Saylor wrote: Hi ( 02.03.15 10:03 - ) Jonathan M. Hollin: However, I request your comments on this idea: should we have just one button (helping to develop a distinct identity for mod_perl) or should we have several (for choice)? It's up to you... TMTOWTDI, of course- multiple buttons! Those of us who have seen the movie Office Space know these as Flair. At least 14 are mandatory! :)
RE: OSC early bird and mod_perl T-Shirts
Maybe this year Randal Schwartz can get his idea implemented. I think he had suggested a motto last year that people seemed OK with but then the T-Shirts never got done in the end... Ah, the annual motto vote... :) Just re-read the same thread in the archives last year. Later, Gunther At 06:55 PM 6/11/2002, John Bass wrote: mod_perl: The camel with wings John -Original Message- From: Lupe Christoph [mailto:[EMAIL PROTECTED]] Sent: 11 June 2002 11:51 To: Leon Brocard Cc: mod_perl list Subject: Re: OSC early bird and mod_perl T-Shirts On Tuesday, 2002-06-11 at 10:44:26 +0100, Leon Brocard wrote: Yup, I have a designer here who is willing to come up with something. Constructive ideas welcome offlist. Better slogans than modperl: the only way to fly, modperl: obey your thirst etc. very welcome too ;-) SCNR: Quetzalcoatl: The Feathered Snake mod_perl: The Feathered Camel Profound excuses, Lupe Christoph -- | [EMAIL PROTECTED] | http://www.lupe-christoph.de/ | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm | __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ Office: (65) 64791172 Mobile: (65) 96218290
Re: separating C from V in MVC
At 12:58 PM 6/14/2002, Dave Rolsky wrote: On Thu, 13 Jun 2002, Rob Nagler wrote: I'm not a big fan of O/R. I prefer R/O. But to each their own. Would one of you mind providing a 1 paragraph definition of each? I am afraid that I am starting to get lost in the semantic differences of controllers and actions and O/R, R/O?
Re: Knowing your limitation - was Re: [JOB] Crack OOP Perl whitebox tester wanted
the role you've outlined here, and to be honest I don't think I would BE as successful as I am if I were located directly with either of these teams. The need to have everyone all together is usually indicative of a larger problem in team dynamics, and communications. It usually represents a team in which charasmatic leadership is more important than technical know how or ability to get a job done. Now don't get me wrong, for a person to BE a successful virtual team member they have to have great communication skills, and be open to working with others in multiple formats to enable the best level of teamwork and participation. With all this said, and based on my own personal experience in this role, I can tell you that what you're asking for here is a person to walk a VERY shape edge between the need to bring the best and brightest from people, without making it seem personal. Actually having this role as an outsider to the day to day politics and interpersonal sabatoge of most bay area offices (yeah I lived there five years during the boom) , gives a layer of abstraction that makes the job easier to perform. When someone is questioning things like style, or code effeciency it comes across MUCH easier (more acadimic) when that person is a talking head, an IM box, or a voice on the telephone. It becomes less personalized and easier to pick and choose the best componants into a greater whole. It also isolates the individual who may end up doing a lot of refactoring to present the final solution. Just something to consider. Open youself to the best people in the world and don't accept just the best you can find in your area, and you'll find that you solutions aren't also as limited... -Zac Morris - Original Message - From: Tom Mornini To: [EMAIL PROTECTED] Sent: Thursday, June 20, 2002 11:30 PM Subject: [JOB] Crack OOP Perl whitebox tester wanted We're 1 year into development of a system that is OO Perl, mod_perl, DBI and DBD::Oracle on Linux. We've spent a lot of energy doing it right and writing tests as we go. This has given us huge benefits in the life of the project, but our current whitebox tester has decided to move to Washington, D.C. so we need somebody to fill his large shoes. If you're a good Perl programmer who has a strong sense of the way it should be and can be simultaneously mean, nasty, angry, distrustful and unforgiving to Perl code and the opposite to people then we'd like to talk to you. This person doesn't do new development, per se, but he is responsible for making things better via testing, fixing, documentation and refactoring. This is a full time job at an office in the South Park area of San Francisco, California, USA. Telecommuters are NOT what we have in mind. Call us old fashioned that way. :-) Pay and benefits are good, though it's no longer 1998. :-) Best benefit is working with a small group of people that are highly motivated by doing it right. -- -- Tom Mornini -- eWingz Systems, Inc. -- -- ICQ: 113526784, AOL, Yahoo, MSN and Jabber: tmornini /blockquote/x-html __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ Office: (65) 64791172 Mobile: (65) 96218290
Re: ANNOUNCE: the new perl.apache.org is alive now!
I agree! It is great work. It looks really slick. Unfortunately, the mod_perl guide documentation area has lost functionality. I wanted to download the latest guide before my 23 hour flight to the USA (to read on the flight) and was dismayed to find hours before my flight that it is impossible to get a full HTML or full PDF download of the entire guide anymore... You can get a PDF of single pages (of which I don't know the reason?), but the guide itself is quite hard. I was able to find a copy on someone else's website... but it was mighty hard on the new one. Anyway, otherwise it looked very slick and was easy to navigate. At 06:10 AM 7/13/2002, David Kaufman wrote: Stas Bekman [EMAIL PROTECTED] wrote: As you may know, the work on the new mod_perl site started in September 2001, and after almost a year we are glad to present to you the outcome of this work at the expected location: http://perl.apache.org/ fist, let me say: Great Job! the new site looks fantastic, a *vast* and long-awaited improvement. i still notice, however that the *content* of the Sites Running mod_perl page doesn't seem to have been updated. about 6 months ago, i sent notices about two sites that we (Vanguard Media) had launched to the email address that used to be on that page, but they were never included. is this being actively maintained now? should i re-send now to the docs-dev mailing list? thanks and, again, Great Work! -dave __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ Office: (65) 64791172 Mobile: (65) 96218290
Getting to the Guide PDF on the new website
At 09:24 PM 7/13/2002, Stas Bekman wrote: Gunther Birznieks wrote: I agree! It is great work. It looks really slick. :) Unfortunately, the mod_perl guide documentation area has lost functionality. I wanted to download the latest guide before my 23 hour flight to the USA (to read on the flight) and was dismayed to find hours before my flight that it is impossible to get a full HTML or full PDF download of the entire guide anymore... You can get a PDF of single pages (of which I don't know the reason?), but the guide itself is quite hard. eh? what do you mean? it's all there, go to: http://perl.apache.org/docs/1.0/guide/index.html click on the pdf button in the right upper corner and you get this: http://perl.apache.org/docs/1.0/guide/guide.pdf Notice though, that parts non-specific to mod_perl 1.0 has now moved to http://perl.apache.org/docs/general/index.html Oh I see it does work. I suppose the PDF buttons on every page is what confused me though. So if you go to the front-page of the docs section, just the front-page gets generated in a PDF, if you go to a page within the guide, then just that section gets generated. The only PDF icon that actually generates a full guide (and it is inconsistent with what the rest of the website PDF icons do) is the actually guide.pdf. A constructive suggestion would be that the icon for PDF on the main guide page should explicitly say PDF of entire guide or something other than the simple PDF icons on all the other pages of the website. Or perhaps remove the PDF icons entirely off the rest of the website. After all, who really wants to generate a PDF of a single HTML page they already read? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ Office: (65) 64791172 Mobile: (65) 96218290
Re: Mixing TOMCAT and mod_perl sessions
What you could do is write an Apache::Session driver that instead of
storing to a file, passes the session id as a call to a web service that
gets and sets session data using parameters sent to a servlet running in
the same context as the sessions where your Java servlets/JSPs run.
I've not done it, but I think it would be awesome if sessions could be
shared between Java Servlets and Perl. We have a lot of apps written in
both technologies ourselves (banking in Java, portal stuff in Perl)
I don't think doing this would be too hard.
Later,
Gunther
At 08:36 PM 8/12/2002, Yair Lenga wrote:
Greetings,
The website I'm supporting is running both TOMCAT applications ('.war'),
and has mod_perl scripts (all of them are registry - CGI scripts). I have
the following requirements:
* The user identification information must be shared between TOMCAT
and mod_perl (so that the user does not need to login twice).
* No data sharing between mod_perl and TOMCAT application - but each
of them need to store some persistent data.
* Session should be persistent across server restarts (which excludes
shared memory based solutions).
I'm currently using 'home-grown' session management, where each session is
represented as a file. Both TOMCAT (4.0.4), and mod_perl (Apache::Session)
can serialize session state. Can anyone suggest a smart way to get the two
to work together - at minimum, I need to be able to create and destroy
sessions, and to have the user id shared between the two. Preferably,
using files (and not mysql).
Thanks,
Yair Lenga
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
Office: (65) 64791172 Mobile: (65) 96218290
OT: Re: Hoping you could give advice
Todd Cranston-Cuebas wrote: Any other thoughts? Yeah, this is off topic, please label it as such. :)
Re: Yahoo is moving to PHP ??
You would think if they want an anal scripting language they would move to python not PHP. :) John Saylor wrote: Hi ( 02.10.30 03:22 -0500 ) Perrin Harkins: They didn't make their decision on performance though. They seem to have been most influenced by the idea that perl allows too much flexibility in coding style, although I can't see how PHP is going to help with that. Wow, I'd like what *they* had for lunch! Quasi-seriously, as someone who has had to maintain mountains of bad perl code, I know TMTOWTDI can have a downside; but the openness of the language is what has lead to its greatness ...
Re: References for modperl usage in financial institutions?
Does it have to be mod_perl in order to help your case? I gave a talk on Perl being used for webapps for investment banking at the 1999 Perl Conference and Morgan Stanley allowed a champion of Perl deliver a keynote at the OReilly Open Source Conference in the year 2000. But neither of us talked about mod_perl specifically. Both presentations might be available from OReilly if you register for their conference portal. I think there may also be a chapter or two on using Perl in a financial institution in the book Applied Perl from the publisher Hungry Minds (IDG or Wiley subsidiary?) (compiled advocacy articles with Peter Williams as editor and author of a couple chapters). Marcin Kasperski wrote: I am looking for some examples of modperl being used in financial institutions (banks, brokers, ... but also large e-commerce). I spent a few hours searching the internet but it seems such a information is not easily available. I am interested in both official and unofficial information. Technical details are not necessary. Thanks in advance for any reply.
Re: Perl Cookbook modperl chapter
Nick, I think you raise valid points that I think Nathan and the reviewers should take on board when they do this chapter and subsequently review it. However... 1) I believe that rather than entirely naysay that some common cookbook items can be covered in a mod_perl chapter, I would prefer to see what Nathan et al come up with rather than discourage them from trying at all. Will it be "futile" as you suggest? Maybe. But then Nathan and the reviewers can choose to cut the chapter. Will it be too complex and therefore cause problems for readers? Maybe. But I think I would trust Nathan and his reviewers to judge after it's done. And again, there is the option of always cutting that chapter as mentioned above. In my past writing life, I've cut plenty of chapters when after seeing a whole book, deciding that they didn't fit (or worse, where it just was a bad chapter I wrote). I suspect Nathan has done the same in his lifetime and I would trust his professionalism in this manner. In other words, I think we should trust that Nathan et al have been writing/editing for a long time. Can they make mistakes? Yes. No one is perfect. But I also trust that their experience will allow them to come up with something for this chapter which will suit a market need. And if it doesn't, to not use that material. But I think it would be sad not to try at all since there could be benefits to this chapter. 2) Will mpdc lose sales? I suppose so. Short-term maybe. But then should Stas stop publishing his book? MacEachern and Stein theirs? Surely they also overlap with mpdc. And there will be other books by other publishers that will overlap with mpdc as well. I suppose that I feel like I am more of an economic optimist than you. While short-term, it may appear that more mod_perl books being released would cause fewer sales in a market that is "fixed", long-term, I believe having more written material about mod_perl will actually help the market. Provided it is done well, I think a chapter in TPC that covers mod_perl explicitly is a good idea also for spreading mod_perl community advocacy and learning. Nick Tonkin wrote: On Wed, 11 Dec 2002, Nathan Torkington wrote: Actually, we do cover mod_perl--we published the Eagle book, "Writing Apache Modules ..." way back in 1999. Yes, I have had my now dog-eared copy since then :) There's no way that 20 recipes in the Perl Cookbook will compete with the what, 250? in the mod_perl Developer's Cookbook. Especially when the introduction and each recipe points the reader to the mpDC. The Perl Cookbook has over a hundred thousand readers. I want to push as many as I can onto the mpDC. If that's competing, then I can only say that you have a strange sense of competition :-) Ahem, well, without wanting to get into a fruitless argument about this part, I might say that you have a strange idea of how to push people onto their book. At close to $50 a pop, I know I'd think twice about purchasing the mpDC if I'd shelled out for the Perl Cookbook and it had a section on mod_perl. I venture to say Geoff et al will see less overall sales, rather than more, if the PCB has a mod_perl section. This notwithstanding the fact that _some_ people _will_ no doubt have their appetite whetted and move on to the definitive mpDC. (Of course there's nothing definitive about Perl, that's the whole point about TMTOWTDI, right?) Trying now to cover highly complex topics like "Authenticating in mod_perl" in a recipe in a chapter of the Perl cookbook is futile. It will only serve to oversimplify and lead novices into a false sense of competence. This was really my point. The Perl Cookbook has never pretended to be the definitive guide to anything it covers (have you seen the Perl Cookbook? I recommend it :-). Each recipe includes references to definitive sources of information (manpages, web sites, and other books). I have also owned the Perl Cookbook since it came out. It's very useful as exactly what it says: a cookbook. You can turn to it for a recipe to accomplish a small, simple task which you guess others may have tackled before you. You can also use it as a tutorial, if you choose to, by studying each chapter as a whole. I do not believe that mod_perl lends itself to the former, and I think that the mpDC more approaches the latter. One can go look up a recipe, true, but it is useless without a pretty thorough prior understanding of mod_perl. So, I stand by my prediction that just putting a few mod_perl recipes in the PCB will lead more than a few people into more problems than solutions. While I've been writing this reply a few people have responded to your request for content suggestions. Stacked handlers, among other things ... I think it just goes to show that there can be no successful trivial coverage of mod_perl. (That's why the Eagle book, and the mpDC, are so good.) - nick
Re: Perl Cookbook modperl chapter
Stas Bekman wrote: Hill, Ronald wrote: It's much simpler than that. You need two sentences: 1) under mod_perl, globals remember their values from the previous request, so you can cache the connection with: $dbh ||= myconnect(); But Apache::DBI implements pinging (immediate or timing based) which is much superior to this. Some databases drop connection otherwise. Or consider the case where the database goes down and then all the $dbh becomes invalid. Apache::DBI would recover gracefully I think. But the above method wouldn't. 2) If you rdbms supports cached statement handles (which most do), you can use Apache::DBI which caches database connection without needing to change any of your code. I am not aware of Apache::DBI caching statement handles. Are you sure that Apache::DBI does this? Or is it a side effect of caching the database handle. If it is the latter, then then caching with #1 above would not solve the problem. If it is the former, perhaps someone can add a global setup variable to Apache::DBI to turn this feature off. eg $Apache::DBI::statement_handle_caching = 0; # default = 1 But of course I agree that it's a good idea to mention this topic. I suggest that many other topics are to be mentioned but replace discussions with pointers to the relevant chapters of the mod_perl books and online documentation. So newbies, know what to look for. It's not obvious that database connections can be cached. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Database Pooling
If I recall correctly, Jeffrey Baker (author of Apache::Session) wrote an extremely lucid and well thought out argument about why the way mod_perl pools connections is just as well as Java in reality. Try searching for his name in the mod_perl list archives.. I think he wrote this over a year ago, but less than 2 years ago. Later, Gunther Michael Teter wrote: Howdy. I'm very new to mod_perl, so if this question makes no sense, say so :) My understanding is that database access via mod_perl is pooled, but only per-httpd. So if I had 10 active httpds running, I would have 10x(number of connections per pool). In contrast, my Java/JSP/Servlet solution has a single pool. I'm trying to evaluate mod_perl to use instead of my current Java-based solution, but the potentially high number of database connections scares me. Do production, public mod_perl-based sites have 10s or 100s of database connections open? Any direction will be appreciated. Michael __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: OSCON ideas - MVC talk
Andy Wardley wrote: Ask Bjoern Hansen wrote: I am planning to submit a proposal for a introduction talk on MVC in a web environment. [...] Like Perrin I would like feedback on the idea before putting in my proposal. I like the sound of it, but I should warn you that I have a personal crusade against inappropriate use of the phrase MVC in relation to web development. I like the sound of the proposal also but more because I think that anything Ask is itching to say is probably going to be interesting. So I trust that he'll give a good talk. However, like you, (but in a different way), I am not necessarily so keen on the topic of MVC. I think most programmers know what MVC is all about, the word is likely mentioned in the docs of most template toolkits which probably has led many people to already read the copious volumes of stuff written on the web about MVC, and likewise the mailing lists of many of the open source Perl toolkits out there probably digress into talking about MVC every 3-6 months at some point. :) In other words, I guess I am not sure how interesting MVC really is (to me). It feels like knowledge of MVC is everywhere to be found. So personally, I would not be interested in an MVC talk just for the sake of imparting knowledge on MVC. But if there was an interesting novel twist to it then that would be more interesting. Perhaps rather than asking our opinion on the title of these talks, a 1-paragraph abstract would be useful to also include in terms of giving an idea of the talk. My limited imagination is kind of turned off on the idea of a talk as an intro to MVC. But if the abstract sounded more interesting than my limited imagination is allowing it to based on a generic title/subject name, then something in that might spark more interest to me. It also could be that an intro talk isn't something that would spark interest on the people on this list because... well, those who are the most vocal here aren't really intro level people. But an intro level talk might interest the silent majority who would pay to attend the conference and could be interested in that Intro knowledge from a mentor instead of reading it on the web. So please don't let my naysaying discourage you. I could be completely wrong. Later, Gunther
Re: OSCON ideas - more talk ideas
Nigel Hamilton wrote: HI, I'd really like to see talks on: 1. Web Server Compression - a comparison, between mod_gzip, DynaGzip Compress etc, pros / cons, SSL compression, and example configurations 2. Application Server Options - a comparison between pure-perl, Apache/mod_perl, POE, SpeedyCGI etc I have done this a couple years ago with Pure-Perl, mod_perl, SpeedyCGI, Velocigen at OSCon. I can forward you my notes if you are interested. But I didn't do it at the level of POE. Comparing POE to mod_perl and SpeedyCGI is kind of like comparing apples and oranges. It feels more apt to compare SOAP::Lite, POE, PerlRPC, ... in terms of a comparison of servers in the same category. And yes, I agree... I would like to see a comparison of SOAP::Lite, POE, PerlRPC, and anything else like them... :) Nige
Re: OSCON ideas
[EMAIL PROTECTED] wrote: I wonder if telecommuting plus occasional travel for face-to-face would sell better than pure telecommuting. Is this done very often in telecommute situations? This is exactly what I hope to propose if the need arises in my situation. Would love to hear from others who have had success doing this (maybe offline if people feel this is straying too far). I don't know if it is really appropriate for OSCon, but I think topics on telecommuting tips and tricks definitely tug at the heart strings of many programmers out there. I know that for my own company, I both like and dislike telecommuting. On the dislike side, I don't think I would ever hire someone whom I did not know for telecommuting even if they came recommended because everyone needs to be managed differently and it's very hard to learn the body language without having been there in person for 6 months to a year. This adds a lot to inefficiency of communication which means money out the window when I could just otherwise hire someone local (unless local talent were not withstanding). But we do support telecommuting. After a couple years with us, our RD director moved to Melbourne (instead of Singapore), and when our webmaster moved back temporarily to New York for personal reasons, he telecommuted for months. Anyway, how to make this on topic for OSCon? I am not sure. Perhaps somewhere in this seed of an idea lies a study/comparison of Open Source Development models and tools being very similar (with perhaps some interesting differences) between telecommuting programmers in a corporation in terms of the methods and tools they use to do their jobs.
Re: OSCON ideas - missing proceedings
Randal L. Schwartz wrote: Nathan == Nathan Torkington [EMAIL PROTECTED] writes: Nathan Not for two years at least (the duration of the contract with the Nathan Portland hotel). The San Diego hotel was much more expensive and Nathan remote, compared to the Portland hotel. I think people are really Nathan going to enjoy being in the middle of a city at this year's OSCON. Yes... the number of things that are within walking distance of the hotel is rather nice. The waterfront park should be rather spectacular, especially at night when the 14 bridges across the Willamette are lit up in their own unique ways. I agree. No matter what, speaking as someone who hasn't travelled around America all that much, I think it's fun to know that the OSCon is in different places every couple of years and to get exposed to those places. Also, speaking as someone who earns money in a non-US currency, having a less expensive place to stay at is much nicer. I am sure the self-employed in the US also feel similarly... (ie anyone who doesn't have a company paying for it...and isn't a shareholder of that company). Later, Gunther
Re: speeding up CGI.pm
Stas Bekman wrote: While we are at the CGI.pm issue, I was thinking that those who stick with CGI.pm because of its extended all-in-one functionality (request parsing/ HTML generation), but unhappy about request parsing speed, could benefit by integrating Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? From an outsider's perspective, I agree. For some previous discussion (April 16, 2000) http://marc.theaimsgroup.com/?l=apache-modperlm=95587404903236w=2
