Re: webmail
At 05/11/2002 01:20 [], David Cantrell wrote: On Mon, Nov 04, 2002 at 01:38:49PM +, Shevek wrote: I do try to stay out of the opinion ring but this, in my opinion, is a steaming pile. Scaling mod_perl up to a few hundred hits a second isn't hard. Scaling perl CGIs up to a few hundred a second is merely hard, but not impossible. Perhaps heretically, I disagree. Until perl can be used (transparent of web server api engines, which don't do a fantastic job anyway) in such a way that multiple concurrent hits doesn't involve an equal number of concurrent running perl instances, cgi perl will not (subject to reasonable hardware constraints) be much use for 100s of instances. Just my $0.02, this isn't intended as a flame. /rataxis -- S. Joel Bernstein :: joel at fysh dot org :: t: 020 8458 2323 Nobody is going to claim that Perl 6's OO is bolted on. Well, except maybe for certain Slashdotters who don't know the difference between rational discussion and cheerleading... -- Larry Wall
Re: webmail
On Tue, Nov 05, 2002 at 01:20:15AM +, David Cantrell wrote: On Mon, Nov 04, 2002 at 01:38:49PM +, Shevek wrote: I do try to stay out of the opinion ring but this, in my opinion, is a steaming pile. Scaling mod_perl up to a few hundred hits a second isn't hard. Scaling perl CGIs up to a few hundred a second is merely hard, but not impossible. Definitely on the difficult side of hard :-) $ time perl -e '$a = `perl -le print q[hello]` for (1..200)' real0m1.068s user0m0.600s sys 0m0.380s $ host -t hinfo paulm.com paulm.com HINFO Intel-1.8GHz-P4 Debian-GNU/Linux $ For fun, $ time perl -e '$a = `perl -MCGI -le print CGI-header, CGI-h1(q[hello])` for (1..200)' real0m10.329s user0m8.400s sys 0m0.990s $ Heh. Paul -- Paul Makepeace ... http://paulm.com/ What is between a duck? A female grizzly and her cub. -- http://paulm.com/toys/surrealism/
Re: webmail
On Tue, Nov 05, 2002 at 03:20:57PM +, Paul Makepeace wrote: On Tue, Nov 05, 2002 at 01:20:15AM +, David Cantrell wrote: Scaling perl CGIs up to a few hundred a second is merely hard, but not impossible. Definitely on the difficult side of hard :-) Agreed. $ time perl -e '$a = `perl -le print q[hello]` for (1..200)' real0m1.068s user0m0.600s sys 0m0.380s $ host -t hinfo paulm.com paulm.com HINFO Intel-1.8GHz-P4 Debian-GNU/Linux $ For fun, $ time perl -e '$a = `perl -MCGI -le print CGI-header, CGI-h1(q[hello])` for (1..200)' real0m10.329s user0m8.400s sys 0m0.990s $ $ time perl -e '$a = `perl -le print q[hello]` for (1..200)' real0m2.353s user0m1.350s sys 0m0.960s $ time perl -e '$a = `perl -MCGI -le print CGI-header, CGI-h1(q[hello])` for(1..200)' real0m22.025s user0m19.560s sys 0m2.350s Here's the first 1%: $ time perl -e '$a = `perl -MCGI= -le print CGI-header, CGI-h1(q[hello])` for(1..200)' real0m21.659s user0m19.370s sys 0m2.280s Scarily, here's another 29%: time perl -e '$a = `perl5.00503 -MCGI= -le print CGI-header, CGI-h1(q[hello])` for(1..200)' real0m15.654s user0m13.930s sys 0m1.610s (perl was 5.8, 5.6.1 built by me, so probably the same compiler options as the other two is: real0m20.931s user0m18.340s sys 0m2.470s ) I think using 5.005_03 is a fair speedup, given that your example isn't using any 5.6.1 features (yet), and isn't tickling any 5.005_03 bugs. Obviously real optimisation problems aren't this simplistic. Nicholas Clark
Re: webmail
S == S Joel Bernstein [EMAIL PROTECTED] writes: Scaling perl CGIs up to a few hundred a second is merely hard, but not impossible. S Perhaps heretically, I disagree. Until perl can be used (transparent S of web server api engines, which don't do a fantastic job anyway) in S such a way that multiple concurrent hits doesn't involve an equal S number of concurrent running perl instances, cgi perl will not S (subject to reasonable hardware constraints) be much use for 100s of S instances. Depends on your hardware, and that's also why this is hard, but not impossible. If you have smaller hardware, you need mod_perl. But that's not what was said here. S Just my $0.02, this isn't intended as a flame. Pay closer attention to context next time, please. That's not a flame either. That's just a whack upside the head. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: webmail
On Mon, Nov 04, 2002 at 01:05:28AM +, Dave Wilson wrote: As a result of this, we now have a steady stream of security vulnerabilities published on major security mailling lists daily about insecure PHP packages (I think this is how the discussion started?). This is true. The actual PHP codebase itself has only had a few insecurities -- I haven't looked at the figures, but at a guess I'd say less than the likes of suidperl (which has been around for quite a long time I must admit, but I'm trying to make PHP look good here). I wouldn't say that using suidperl is safe, but using perl as a whole, invoked by root, is not a bad thing. PHP has had remote attacks against it: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=mod_php Though I thought that there had been more than just that one. A remote arbitrary code execution vulnerability is considerably more dangerous than a local privilege escalation, in general. What this boils down to, is that a) I don't believe that scalable and maintainable sites can be easily written in PHP b) I don't believe that the general coding standard in the PHP binaries is as high as is necessary to survive on the modern Internet Therefore I'm not likely to run it anytime soon. YM will almost certainly V -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: webmail
On Mon, Nov 04, 2002 at 09:06:43AM +, Lusercop wrote: As a result of this, we now have a steady stream of security vulnerabilities published on major security mailling lists daily about insecure PHP packages (I think this is how the discussion started?). This is true. I'm gratified by your blessing. The actual PHP codebase itself has only had a few insecurities -- I haven't looked at the figures, but at a guess I'd say less than the likes of suidperl (which has been around for quite a long time I must admit, but I'm trying to make PHP look good here). I wouldn't say that using suidperl is safe, but using perl as a whole, invoked by root, is not a bad thing. PHP has had remote attacks against it: So, a uid 0 script is fine, as long as it wasn't started suid? heh. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=mod_php Though I thought that there had been more than just that one. A remote arbitrary code execution vulnerability is considerably more dangerous than a local privilege escalation, in general. As far as actual holes are concerned (and I'm rather drunk right now, yes, at this time of the morning), I think there have only been two (2) in PHP 4. PHP 3 is not PHP. It's shit. :) What this boils down to, is that a) I don't believe that scalable and maintainable sites can be easily written in PHP I addressed this. It is because you suck, not the language. I thought people liked perl because of it's flexibility. And define scalability. mod_perl vs. mod_php are both equally as scaleable, ie. they rely on the Apache host. I could even argue PHP is more scaleable due its ability to run on top of shitloads of APIs. So, when your site breaks the 2 hits/sec threshold, and you need a scaleable web server and Apache is not it, a FastCGI or ISAPI-capable host might be. b) I don't believe that the general coding standard in the PHP binaries is as high as is necessary to survive on the modern Internet And you've read them, as well as perl. I'm impressed -- how old are you? As someone who's debugged, modified, and written extensions for PHP, I'd say it's one of the nicer programs around to work on. Fundamental vulnerabilities are not uncommon -- in fact, you're guaranteed at least one fuckup a month these days. PHP's POST handling vulnerability was such a thing. This doesn't mean you loose all confidence in it. Therefore I'm not likely to run it anytime soon. If I were in charge of a production PHP environment (thanks to the N. Ireland I.T. industry, I'm not), it wouldn't be running facing the Internet directly. Then again, neither would mod_perl or any other large program with bits I hadn't explored. At this point, I'd like to declare the classic security is a myth followed by end of thread, before this develops into a PHP vs. Perl, which I c.b.a. with. Dave.
Re: webmail
On Mon, 4 Nov 2002, Dave Wilson wrote:
On Mon, Nov 04, 2002 at 09:06:43AM +, Lusercop wrote:
Though I thought that there had been more than just that one. A remote
arbitrary code execution vulnerability is considerably more dangerous
than a local privilege escalation, in general.
As far as actual holes are concerned (and I'm rather drunk right now,
yes, at this time of the morning), I think there have only been two (2)
in PHP 4. PHP 3 is not PHP. It's shit. :)
I remember people saying this about W3.11 when W95 came out.
I remember people saying this about W95 when W98 came out.
I remember people saying this about W98 when WNT came out.
After that I lose track.
It's still kind of funny though, when people dis' a previous version.
Following this are just comments on the thread which the saner members of
the list are advised neither to read nor reply to.
S.
-- flamage below --
What this boils down to, is that
a) I don't believe that scalable and maintainable sites can be easily
written in PHP
I addressed this. It is because you suck, not the language. I thought
people liked perl because of it's flexibility.
And define scalability. mod_perl vs. mod_php are both equally as
scaleable, ie. they rely on the Apache host. I could even argue PHP is
more scaleable due its ability to run on top of shitloads of APIs. So,
when your site breaks the 2 hits/sec threshold, and you need a scaleable
web server and Apache is not it, a FastCGI or ISAPI-capable host might be.
I do try to stay out of the opinion ring but this, in my opinion, is a
steaming pile. Scaling mod_perl up to a few hundred hits a second isn't
hard. Scaling PHP to that isn't possible.
If I were in charge of a production PHP environment (thanks to the N.
Ireland I.T. industry, I'm not), it wouldn't be running facing the
Internet directly. Then again, neither would mod_perl or any other large
program with bits I hadn't explored.
Like the kernel, for example. *grin*
S.
--
Shevek
I am the Borg.
sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print$x\n;eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;{$x}(\$x);};};}
foreach my $i (3..65535) { {'2'}($i); }
Re: Re: webmail
On Mon, 4 Nov 2002, Shevek wrote: I remember people saying this about W3.11 when W95 came out. I remember people saying this about W95 when W98 came out. I remember people saying this about W98 when WNT came out. Not to be too picky or anything, but... WNT was first released before W3.11. It was then updated twice before W95 was released, and once again before W98. For a nice timeline, see http://www.computerhope.com/history/windows.htm Jody
Living in glass houses was: [Re: webmail]
On Mon, Nov 04, 2002 at 12:17:40PM +, Dave Wilson wrote: What this boils down to, is that a) I don't believe that scalable and maintainable sites can be easily written in PHP I addressed this. It is because you suck, not the language. I thought people liked perl because of it's flexibility. Shock move: Dave Wilson tells someone else that their coding sucks. b) I don't believe that the general coding standard in the PHP binaries is as high as is necessary to survive on the modern Internet And you've read them, as well as perl. I'm impressed -- how old are you? As someone who's debugged, modified, and written extensions for PHP, I'd say it's one of the nicer programs around to work on. Fundamental vulnerabilities are not uncommon -- in fact, you're guaranteed at least one fuckup a month these days. PHP's POST handling vulnerability was such a thing. This doesn't mean you loose all confidence in it. As someone who's debugged, modified, and written extensions for PHP, you seemed to have an inordinate amount of trouble coding one simple Linux Users Group web site. I'd give your opinion on this more respect if you hadn't made a total pigs arse of the BLUG website. In fact, didn't you leave it sitting broken and unusable for months on end. The only reason you fixed it is because you were publicly berated and badgered. In response to the public badgering, you put up something that half worked. Eleven odd months later, is it actually working yet? If I remember it correctly, you broke a perfectly servicable set of static web pages so you could write it from scratch in PHP. What percentage of your proposed new features did you actually implement? I realise that none of this is relevant to whether PHP is inferior to perl. It does however relate directly to your qualifications to pontificate on the subject. andrew -- Virgo: (Aug. 23 - Sept. 22) And to think you laughed when your high-school yearbook named you Most Likely To Be Responsible For The Extinction Of The Frigate Bird.
Re: Living in glass houses was: [Re: webmail]
On Mon, Nov 04, 2002 at 03:36:55PM +, Andrew Wilson wrote: [Wilson-on-Wilson flame action snipped] OK, how many of you Wilsons are related? It's rapidly turning into a Dave situation. I for one am losing track... P -- Paul Makepeace ... http://paulm.com/ What is the smell of red? Foolish pride! -- http://paulm.com/toys/surrealism/
Re: Living in glass houses was: [Re: webmail]
On Mon, Nov 04, 2002 at 03:48:47PM +, Paul Makepeace wrote: On Mon, Nov 04, 2002 at 03:36:55PM +, Andrew Wilson wrote: [Wilson-on-Wilson flame action snipped] OK, how many of you Wilsons are related? It's rapidly turning into a Dave situation. I for one am losing track... Oh Dave and I aren't related. Unless you count both of us being memebers of the previously mentioned linux users group committee. andrew -- Taurus: (April. 20 - May 20) It's all over but the shouting, but don't worry: It's going to be great shouting. msg08952/pgp0.pgp Description: PGP signature
Re: Living in glass houses was: [Re: webmail]
* Andrew Wilson ([EMAIL PROTECTED]) wrote: I realise that none of this is relevant to whether PHP is inferior to perl. It does however relate directly to your qualifications to pontificate on the subject. can we please skip the now inevitable mudslinging argument, its too near chrimbo for this sort of thing (m, duck, mm) Greg -- Greg McCarroll http://www.mccarroll.org.uk/~gem/ jabber:[EMAIL PROTECTED]
Re: Living in glass houses was: [Re: webmail]
On Mon, Nov 04, 2002 at 03:36:55PM +, Andrew Wilson said: As someone who's debugged, modified, and written extensions for PHP, you seemed to have an inordinate amount of trouble coding one simple Linux Users Group web site. Umm. To quote a certain bunch of stereotyped scoursers on a p[opular comedy show Calm down I'm hoping that we can have a a sensible discussion about programming languages without resulting to personal digs because, well, WE'RE NOT F*CKING 14 ANYMORE. Play nice children, and do try to get along. Otherwise we're no better than Java programmers. [0] Simon [0] he says, working on the Give everybodsy a common enemy and they'll get along school of management [1] [1] And by the way, it was a joke. [2] [2] And yes I am actually a Java programmer. [3] [3] Well, I was untila bout a month ago.
Re: Living in glass houses was: [Re: webmail]
On Mon, Nov 04, 2002 at 03:54:14PM +, Greg McCarroll wrote: * Andrew Wilson ([EMAIL PROTECTED]) wrote: I realise that none of this is relevant to whether PHP is inferior to perl. It does however relate directly to your qualifications to pontificate on the subject. can we please skip the now inevitable mudslinging argument, its too near chrimbo for this sort of thing (m, duck, mm) Sure, I've slung all the mud I intend to about the subject. andrew -- Leo: (July 23 - Aug. 22) You understand that if you're not part of the solution, you're part of the problem, but you still aren't sure which is supposed to be better. msg08955/pgp0.pgp Description: PGP signature
Re: Living in glass houses was: [Re: webmail]
On Mon, Nov 04, 2002 at 03:54:14PM +, Greg McCarroll ([EMAIL PROTECTED]) wrote: can we please skip the now inevitable mudslinging argument, its too near chrimbo for this sort of thing (m, duck, mm) Don't get me started on bloody christmas! Dave... -- It was long ago and it was far away And it was so much better that it is today
Re: webmail
On Mon, Nov 04, 2002 at 09:06:43AM +, Lusercop wrote: I wouldn't say that using suidperl is safe, but using perl as a whole, invoked by root, is not a bad thing. PHP has had remote attacks against it: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=mod_php Though I thought that there had been more than just that one. A remote Perhaps you're thinking of Apache which has had plenty of remote roots... What this boils down to, is that a) I don't believe that scalable and maintainable sites can be easily written in PHP Scalable how? It's certainly capable of serving millions of hits a day. The article on amihotornot's creation is worth a read, and that's a LAMPHP site, http://www.webtechniques.com/archives/2001/05/hong/ b) I don't believe that the general coding standard in the PHP binaries is as high as is necessary to survive on the modern Internet Well this is patently empirically shown to be false, since there are millions of installed PHP systems quite happily surviving (specifically, staying up and not causing the administrator to unload PHP in horror at the onslaught of attacks). Although my comment about Apache was sarcastic it does seem odd that people level these criticisms against Language X and yet the webserver they *require* is apparently much more prone and dangerous, based on the sheer number of serious vulnerabilities, let alone actual live exploits, against it. Someone I think Roger said (as I read it) there were lots of exploits against PHP, but there too a lack of citation somewhat undermines that stance. I've been running nessus in dangerous mode against my servers for quite some time and more recently ISS and it's never found a problem with PHP. I'm not trying to persuade you to run PHP nor to be honest particularly advocating it (I'm a mod_perl/TT sort of person after all!) but rather that these kinds of broad statements really need to be thorough backed up with facts and citations. If the open source community is going to criticize the commercial world (namely, MS for the most part) for sloppiness and FUD then they need to keep their nose very clean, IMO. Paul -- Paul Makepeace ... http://paulm.com/ What is an airplane? It can only be street-cleaning. -- http://paulm.com/toys/surrealism/
Re: Living in glass houses was: [Re: webmail]
* Simon Wistow ([EMAIL PROTECTED]) wrote: Play nice children, and do try to get along. Otherwise we're no better than Java programmers. [X0] [X0] he says, working on the Give everybodsy a common enemy and they'll get along school of management [X1] scarily this isn't too bad a suggestion[2], if we were to look at who our `enemies' were, they would more likely be Java and C++ --- ``Higher''[1] Level Languages that do not embrace the dynamic nature of Perl, and our allies PHP and Python. I do not see C as an enemy as I think it occupies an entirely different problem space, however Java is exactly in the area where Perl is excellent, imho, ymmv, idrciyd Greg [1] Than C and Pascal at least [2] And I'm not joking. -- Greg McCarroll http://www.mccarroll.org.uk/~gem/ jabber:[EMAIL PROTECTED]
Re: webmail
On Mon, 4 Nov 2002, Paul Makepeace wrote: b) I don't believe that the general coding standard in the PHP binaries is as high as is necessary to survive on the modern Internet Well this is patently empirically shown to be false, since there are millions of installed PHP systems quite happily surviving (specifically, staying up and not causing the administrator to unload PHP in horror at the onslaught of attacks). You don't see all the machine pull and rebuild requests that get filed each time someone discovers a hole, and discovers our netblocks. Not that most of the compromised users use PHP or even know it's installed (as people mentioned in the netcraft thing) Then they reinstall all their content, with their server all patched up to the currently by our build process, and wait for the next exploit (php or otherwise). the hatter
Re: webmail
On Mon, 2002-11-04 at 16:30, Paul Makepeace wrote: Scalable how? It's certainly capable of serving millions of hits a day. The article on amihotornot's creation is worth a read, and that's a LAMPHP site, http://www.webtechniques.com/archives/2001/05/hong/ Yeah, and I remember the hell he went through when he first got real traffic to his site.
Re: webmail
On Mon, Nov 04, 2002 at 01:05:28AM +, Dave Wilson wrote: b) The number of bad PHP programmers: A properly coded PHP project should be just as secure as it's perl or C (or insert-language-here) counterparts. It is the In-24-hrs-Newbie who is writing code like 'system(getenv(USERNAME));'. This could just as easily be done in any other language. (please skip the perl tainting rants :). Here are a couple of articles on developing Rock Solid PHP, http://www-106.ibm.com/developerworks/library/wa-phprock1/?t=gr,lnxw10=PHBvariables1 http://www-106.ibm.com/developerworks/web/library/wa-phprock2/?t=gr,lnxw10=PHBvariables2 (via http://www.linuxformat.co.uk/modules.php?op=modloadname=Newsfile=articlesid=550 ) Let's not lose sight of why we're here - software is for most of us probably more practical than theoretical. That means writing and using the stuff. I'm personally glad to see people writing software. We all had to start somewhere - if PHP is an entry point for people then great, we get to use more software (there's no shortage of examples of major pieces of extant PHP software that aren't matched in the perl world). Those people will learn to write code, become part of the open source community, and they'll get better and write better software. Who knows, they may even graduate to perl... :-) Paul -- Paul Makepeace ... http://paulm.com/ What is the likelihood of promotion? Desperate thrashing in a supermarket. -- http://paulm.com/toys/surrealism/
Re: webmail
On Mon, Nov 04, 2002 at 06:16:13PM +, Dave Hodgkinson wrote: On Mon, 2002-11-04 at 16:30, Paul Makepeace wrote: Scalable how? It's certainly capable of serving millions of hits a day. The article on amihotornot's creation is worth a read, and that's a LAMPHP site, http://www.webtechniques.com/archives/2001/05/hong/ Yeah, and I remember the hell he went through when he first got real traffic to his site. And...? Did PHP prevent it scaling? Or prevent it being maintainable? P -- Paul Makepeace ... http://paulm.com/ If drawing is like riding a bike, then some masks would be smarter than others. -- http://paulm.com/toys/surrealism/
Re: webmail
On Mon, 2002-11-04 at 18:22, Paul Makepeace wrote: On Mon, Nov 04, 2002 at 06:16:13PM +, Dave Hodgkinson wrote: On Mon, 2002-11-04 at 16:30, Paul Makepeace wrote: Scalable how? It's certainly capable of serving millions of hits a day. The article on amihotornot's creation is worth a read, and that's a LAMPHP site, http://www.webtechniques.com/archives/2001/05/hong/ Yeah, and I remember the hell he went through when he first got real traffic to his site. And...? Did PHP prevent it scaling? Or prevent it being maintainable? He was hammering MySQL. Lots of updating of tables. Decent hardware, more memory, delayed updates and vertical partitioning (read-only tables and squiddly little frequently updated tables) got him rolling. ISTR. PHP is pretty good at being front-facing, being much lighter than mod_perl, but that can also lead to CPU chewing. I'm a big fan of limited numbers of apache processes at the backend!
Re: webmail
On Mon, Nov 04, 2002 at 01:38:49PM +, Shevek wrote: I do try to stay out of the opinion ring but this, in my opinion, is a steaming pile. Scaling mod_perl up to a few hundred hits a second isn't hard. Scaling perl CGIs up to a few hundred a second is merely hard, but not impossible. -- Lord Protector David Cantrell | http://www.cantrell.org.uk/david If a job's worth doing, it's worth dieing for
Re: webmail
On Wed, Oct 30, 2002 at 07:49:03PM -0800, Randal L. Schwartz wrote: Paul == Paul Makepeace [EMAIL PROTECTED] writes: Paul I am also amused and puzzled at the people writing huge tracts on why Paul PHP is crap while not at the same time acknowledging there are vastly Paul more websites written in PHP doing useful things for lots of people than Paul there are in perl -- witness the scrabbling to find even remotely Paul interesting success story cases for Perl (what recent ones have there Paul been?). A lot of the ones at http://perl.apache.org/outstanding/success_stories/ seem recent. And I suppose you haven't heard of match.com or citysearch.com or ticketmaster.com before? Oh wait, you're a brit. :) That's good to see -- match.com is certainly a massive site. Still, it seems a tiny number to me considering what's out there. Paul I suspect more revenue is generated from PHP sites than Perl Paul sites. I don't. I suspect PHP runs more hobby sites. I suspect Perl does more of the e-commerce heavy lifting and pretty-lifting. I dunno, in light of reports like the one on LWN I'm struggling to see this. PHP Overtakes Microsoft's ASP as Web's #1 Server-side Scripting Language: http://lwn.net/Articles/1433/ According to a Netcraft survey published in April 2002, PHP is now being used by over 24% of the sites on the Internet. Of the 37.6 million web sites reported worldwide (http://www.netcraft.com/Survey/index-200204.html), PHP is running on over 9 million sites and continues to grow at an explosive rate. Over the past two years PHP has averaged a 6.5% monthly growth rate. That's an enormous number of hobby sites :-) Oh well, who knows - my basic point is that for all the interesting discussion about how bad PHP is there's an awful lot of productive work going on with it, that same work that probably wouldn't've happened with perl. (I know at least half a dozen PHPers who were too scared by perl.) Paul -- Paul Makepeace ... http://paulm.com/ If I could write Java Code, then some masks would be smarter than others. -- http://paulm.com/toys/surrealism/
Re: webmail
On Mon, Nov 04, 2002 at 12:44:00AM +, Paul Makepeace wrote: According to a Netcraft survey published in April 2002, PHP is now being used by over 24% of the sites on the Internet. Of the 37.6 million web sites reported worldwide (http://www.netcraft.com/Survey/index-200204.html), PHP is running on over 9 million sites and continues to grow at an explosive rate. Over the past two years PHP has averaged a 6.5% monthly growth rate. That's an enormous number of hobby sites :-) Oh well, who knows - my basic point is that for all the interesting discussion about how bad PHP is there's an awful lot of productive work going on with it, that same work that probably wouldn't've happened with perl. (I know at least half a dozen PHPers who were too scared by perl.) I think the bad publicity that PHP gets is largely due to two/three things: a) The speed at which it evolves: PHP has went through a crazy development cycle in the last year or two.. quite a bit of the API changed to be more uniform, and other such language enhancements. This period is not over, Zend2 is on the way which will change some of the language syntax, although on saying that, perl6 is on the way too, and perl's syntax will probably change more than PHP's will with this upgrade. b) The number of bad PHP programmers: PHP is probably one of the easiest web languages in the world to pick up. Given that, and the number of .* in 24 hours books available for it, the universe now has a surplus of PHP coders who don't really know what they are doing. As a result of this, we now have a steady stream of security vulnerabilities published on major security mailling lists daily about insecure PHP packages (I think this is how the discussion started?). The actual PHP codebase itself has only had a few insecurities -- I haven't looked at the figures, but at a guess I'd say less than the likes of suidperl (which has been around for quite a long time I must admit, but I'm trying to make PHP look good here). A properly coded PHP project should be just as secure as it's perl or C (or insert-language-here) counterparts. It is the In-24-hrs-Newbie who is writing code like 'system(getenv(USERNAME));'. This could just as easily be done in any other language. (please skip the perl tainting rants :). c) Lack of traditions regarding project management and syntax style: Well organized PHP projects are few and far between; I've heard hundreds of anti-PHP arguments, most of them valid, but a large number have been that PHP does not cope well when given a large codebase (1000+ lines). If your PHP codebase has got messy, that is your fault, not the languages. PHP doesn't have a recognized way of organizing code (like Perl or Python modules), it leaves it up to you to be creative in finding a way. As a side note, there is a CPAN clone well under way, however, PEAR. The only real complaint I have with PHP is the memory management, which I have seen get messy in really simple situations. Apart from that, it's a nice neat little language. If you keep up with the development of the language (like any good programmer should anyway), you're sorted. Admittedly, PHP language development moves about 100 times faster then any other language at times, but thats just it's nature. /rant Dave.
Re: webmail
On 04/11/02 00:44 +, Paul Makepeace wrote: I dunno, in light of reports like the one on LWN I'm struggling to see this. PHP Overtakes Microsoft's ASP as Web's #1 Server-side Scripting Language: http://lwn.net/Articles/1433/ According to a Netcraft survey published in April 2002, PHP is now being used by over 24% of the sites on the Internet. Of the 37.6 million web sites reported worldwide (http://www.netcraft.com/Survey/index-200204.html), PHP is running on over 9 million sites and continues to grow at an explosive rate. Over the past two years PHP has averaged a 6.5% monthly growth rate. That's an enormous number of hobby sites :-) Current or ex-Netcrafters can correct me if I'm wrong, but the netcraft survey basically asks the http server what it's actually running, and so these figures are, pretty much, simply taken from distinct domains with an apache reporting that it has mod_php loaded. There are 2 major points with this: 1) Whilst mod_perl shows up in the same way, there's no direct way of Netcraft collecting data on vanilla apache servers which are being used with perl scripts (CGI.pm-enabled or otherwise). 2) Many servers, especially those at bulk hosting companies running virtual hosts for people, will be compiled with mod_php by default. Whether it's actually used by any/all of the sites on the box is a different point. The statistics may not be that accurate, basically. Having said that, I don't doubt that PHP is popular, and that it's very useful for a lot of people in a lot of situations. Personally I haven't used it very much (my old not-quite-dormant company has a couple of sites running geeklog, but that's pretty much someone else's responsibility), and I like the flexibility and power that I have with perl, especially combined with DBI and TT. Each to their own, horses for courses, and a bunch of other cliches...
Re: webmail
Adrian Howard wrote: You might also want to take a look at YAML http://yaml.org/ - there's a YAML.pm already in CPAN. YAML is something totally different. It's (essentially) for data serialisation without the overhead of XML. AML is designed for humans to write. More like POD than XML or YAML. They're alternate XML syntaxes that use indentation (Python anyone) I'm afraid that's a non-starter with me then. The only reason I've never got beyond page 1 learning python. A
Re: webmail
David Cantrell wrote:
Let me clear up a few things here. I wrote my toy system because I had an
itch which needed scratching.
Great!
The only reason I'm even bothering
to argue about this is because of the incorrect assertions coming from
people who really should know better that my sort of solution inevitably
leads to spaghetti code and all the rest of the nastiness from Revelations.
Er no. Well, not me at least. I've said absolutely nothing about your
solution. You clearly understand the principle of separating application
from presentation. The fact that you're using Perl syntax code is neither
here nor there - it's what you do with it that matters.
The point I originally made was that *PHP* doesn't allow you to make this
clear distinction. Sure you can write separate modules but they're still
embedded-in-the-HTML type and the whole flat namespace thing makes it
hard to plug separate modules back together.
So I stand by my point. Using *PHP* tends to lead to a poor separation of
concerns typified by spaghetti code.
I certainly wasn't having a dig at your personal template solution. In
fact, I think you're the only person who has mentioned it. The rest of
us are talking about *PHP* :-)
There is one point I would like to make about syntax, however. For TT
I deliberately chose an abstract syntax (e.g. 'user.name') rather than
sticking with Perl syntax (e.g. $user-{ name }). For one, I find this
simpler to read and write. But more importantly, it allows the underlying
data types to change without requiring changes to the templates. An
abstraction of the implementation, if you like.
For testing purpose, you can define a hash of data which your page designers
(or you) can use to mock up the web pages. Later on, you can replace the
use hash with an object and the same template sytax will call object methods
instead of referencing hash items.
In Perl you have to care about the difference between $user-name() and
$user-{ name }. But TT hides all that from you. I think that's the
Right Way To Do It. When you're doing presentation you shouldn't be
worrying about different data types and other programming crap like
that. You want the name of the user and you don't (or shouldn't) care
where it comes from or how it is calculated. That's for the back-end
code and data designers to worry about.
Some people think that calling object methods from a template is a no-no
because it changes flow control. Personally I think this is nonsense.
Your example code demonstrates this point well. What matters is how you
partition the system. Things that deal with one thing should be in one
place. Things that deal with another should be in another. The particular
language, syntax or implementation details are largely irrelevant.
That's why it's possible to write wonderfully clean, highly abstracted
systems using embedded Perl, and dog-awful, messy, entangled systems
using TT or even HTML::Template (which claims to be so strict that you
can't do this, yeah right :-)
A
Re: webmail
* Andy Wardley ([EMAIL PROTECTED]) wrote:
There is one point I would like to make about syntax, however. For TT
I deliberately chose an abstract syntax (e.g. 'user.name') rather than
sticking with Perl syntax (e.g. $user-{ name }).
So can we look forward to user-name under Perl 6? ;-)
Greg
--
Greg McCarroll http://www.mccarroll.org.uk/~gem/
jabber:[EMAIL PROTECTED]
Re: webmail
Andy Wardley said:
In Perl you have to care about the difference between $user-name() and
$user-{ name }. But TT hides all that from you. I think that's the
Right Way To Do It. When you're doing presentation you shouldn't be
worrying about different data types and other programming crap like
that. You want the name of the user and you don't (or shouldn't) care
where it comes from or how it is calculated. That's for the back-end
code and data designers to worry about.
I agree that this is wrong. In OO terms, it exposes the impementation to
the user. It's wrong for templates, but it's also wrong for ordinary
classes. If I decide that I want to change some part of the interface
from being a plain integer to calling a method, why should the users of
the class care.
Languages such as Eiffel have got this right, and yes Greg, Perl 6 will
too :-)
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: webmail
Greg McCarroll wrote: So can we look forward to user-name under Perl 6? ;-) Nope, user.name :-) A
Re: webmail
On Thu, 31 Oct 2002, Paul Makepeace wrote: On Wed, Oct 30, 2002 at 04:38:12PM -0500, Chris Devers wrote: On Wed, 30 Oct 2002, everyone wrote: PHP is crap I don't think PHP is crap. I am also amused and puzzled at the people writing huge tracts on why PHP is crap while not at the same time acknowledging there are vastly more websites written in PHP doing useful things for lots of people than there are in perl -- witness the scrabbling to find even remotely interesting success story cases for Perl (what recent ones have there been?). I suspect more revenue is generated from PHP sites than Perl sites. As a corollary, there are less (by some metric) experienced people writing more web software in PHP than in Perl. PHP gets you sooo much more with the same amount of effort than with perl. PHP is fundamentally quite easy, the learning curve astonishingly flat. Hardly the case for perl. The learning curve to writing *bad* PHP is really flat. The learning curve to writing good, secure, scalable PHP I would suggest is much steeper and longer, because the language itself, and also the user community (and so the support and resources available) is so geared to writing quick-hack code. Just look at the user comments on the PHP manual. I'm sure there are people writing good PHP out there - the Horde and IMP stuff I was quite impressed with - but they are lost in the noise of people arguing the PHP equivalents of 'use strict is gay' over and over. Worse is better. Indeed. Perhaps there's a lesson there - but I'll stick to my Lisp Machine, thanks. Chris.
Re: Webmail
On Wed, 2002-10-30 at 22:42, Chris Devers wrote:
On 30 Oct 2002, Dave Hodgkinson wrote:
does anyone have any recommendations for webmail that won't degenerate
into a templating argument?
Yeah, I'm impressed that in all this thread (over 100 messages?) I think
maybe one or two posts actually addressed the question. I was also looking
forward to an answer to this one. If Squirrelmail is bad because it's PHP
and $hand_rolled_with{$template} is even worse, then what doesn't suck?
I'd also like to set up such a thing, if any projects out there came
recommended highly enough. Apparently nothing is better than all of them?
You'll be happy to know that SquirrelMail developers are looking into
templating it properly, but are concentrating more on cleaning up the
code first :)
--
Simon
Re: webmail
* Chris Andrews ([EMAIL PROTECTED]) wrote: The learning curve to writing *bad* PHP is really flat. The learning curve to writing good, secure, scalable PHP I would suggest is much steeper and longer, because the language itself, and also the user community (and so the support and resources available) is so geared to writing quick-hack code. Which was the state of Perl *plucks figure out of the air* 4 years ago. However during this time we've seen great advances in the way people develop in Perl. Off the top of my head I'd suggest the major forces in this advancement are (and this is imho), * Testing Testing has become easier and more fun in Perl, thanks to all the modules, articles, talks on the subject. (At this point I'd like to suggest to anyone who hasn't looked at Test::MockObject to look at it today) * Template Toolkit Like TT or not, the emergence of a dominant templating system has stopped people in a lot of cases rolling their own, or hacking their own extensions onto H::T. * YAPC YAPC conferences have meant there are a low cost alternative to TPC, meaning that people can still meet with their peers and learn from talks/tutorials even if they can't afford TPC. * Perl 6 Perl 6 is acting as a stimulus for the way people think about Perl and the Perl community (and its relationship to Python, Java, et al.) Also I'm hoping we will see some aspects of Perl 6 make their way into 5.10 but there are already lots of modules on CPAN emulating Perl 6 RFC suggestions. Of all the driving forces this is perhaps the one which we haven't seen the most impact from so far, but I believe we will see more and more impact from it, in the next 6~12 months. I've probably forgotten some of the improvements in the world of Perl during this time, but the point remains Perl has matured in ``software engineering'' terms, whatever that means and PHP still has to do so. Anyway, thats just me tuppence ha'penny worth, Greg -- Greg McCarroll http://www.mccarroll.org.uk/~gem/ jabber:[EMAIL PROTECTED]
Re: webmail
On Thu, Oct 31, 2002 at 09:27:14AM +, Greg McCarroll ([EMAIL PROTECTED]) wrote: * Chris Andrews ([EMAIL PROTECTED]) wrote: The learning curve to writing *bad* PHP is really flat. The learning curve to writing good, secure, scalable PHP I would suggest is much steeper and longer, because the language itself, and also the user community (and so the support and resources available) is so geared to writing quick-hack code. Which was the state of Perl *plucks figure out of the air* 4 years ago. However during this time we've seen great advances in the way people develop in Perl. Off the top of my head I'd suggest the major forces in this advancement are (and this is imho), [snip] * YAPC YAPC conferences have meant there are a low cost alternative to TPC, meaning that people can still meet with their peers and learn from talks/tutorials even if they can't afford TPC. At a lower level, I'd say the the Perl Mongers movement has also contributed a great deal in getting Perl programmers talking to each other. For example, how many of your had met 5 other Perl programmers before joining london.pm? I know I hadn't. Dave... -- Brian: Oh screw Maximilian! Sally: I do. Brian: So do I.
Re: Webmail
On 30 Oct 2002, Dave Hodgkinson wrote: does anyone have any recommendations for webmail that won't degenerate into a templating argument? http://fastmail.fm OK, you can't install it anywhere, but it's far and away the best webmail service out there. Supporting evidence includes: * It plays nicely with IMAP and IMAPS * It's written in Perl (hence this post is not OT ;) and it's maintainers have contribued at least one module to CPAN * It lets you use your own domains, and there are lots of others besides fastmail.fm to choose from (like the particularly cool eml.cc) * It has lots of the Funky Filtering Features that you'd probably want to set up if you were hosting your own mailserver (like if a folder named 'folder' exists in your IMAP directory, mail to [EMAIL PROTECTED] gets automatically filed into it, as does mail to [EMAIL PROTECTED]) * You can write whatever horribly complex filtering rules you want in Sieve, the Cyrus mail filtering language * It has SpamAssassin and virus scanning already set up and running * You can get whatever bandwidth and storage limits you want * If you're looking to do corporate webmail, you can get them to change the interface or set up a new CSS for your corporate LF * The interface is very good, clean, and uses almost no graphics so downloads fast for people on a slow connection * and probably more features that I haven't mentioned There's even a free option if you want, but the paid-for options are not expensive. No, I don't work for them. I just think they're good. (But on the shameless plug note, if you do sign up, the correct answer when they ask you for a referrer is 'mas' ;). Michael
Re: webmail
On Wed, Oct 30, 2002 at 07:49:03PM -0800, Randal L. Schwartz said: I don't. I suspect PHP runs more hobby sites. I suspect Perl does more of the e-commerce heavy lifting and pretty-lifting. Christ. I said I wasn't going to get pulled into this. FWIW, according to the latest SecuritySpace survey (http://www.securityspace.com/s_survey/data/man.200209/apachemods.html) the number of mod_perl and mod_php installations is comparable (I've taken to ignore the percentage changes because, a couple of months ago, Perl was growing by 25% a month whilst PHP was decreasing by 12%)/ This of course doesn't count the number of places running Perl scripts as plain CGIs. As for the Yahoo! thing - I can only tell you so much but, as mentioned in the report, we have *lots* of Perl code and our publishing system is written almost entirely in Perl. Currently we use 3 different templating languages - all proprietary - some dating back almost from the days Yahoo! started. I have had a long discussion with the other engineers and pointed out TT (which I thought would have been a better match since we're slinging Perl objects from the publishing system) and they we suitably impressed and may steal some ideas. From what I can tell the reason for switching to PHP is (a) politics and (b) all our current code is mixed code and presentation because, as I mentioned, some of it dates back from days of yore. Converting to PHP is a lot easier than converting to, say, TT. I think, anyway. People are a bit cagey about the whole thing. -- an atmosphere of PhD student with a touch of alternative elitist radical
Re: Webmail
Dean Wilson wrote: I'm going to ignore the PHP bashing and templating discussions and add that Horde and SquirrelMail are both recommened on the GLLUG list when ever this question comes up by a number of people. So while neither is written in Perl both are in use. I'm using an IMAP server here and never managed to get horde working properly. Squirrelmail, OTOH, worked pretty much straight out of the box. It does have a few quirks which I haven't ironed out yet though. -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
php irony, was Re: webmail
On Wed, 30 Oct 2002, Andy Wardley wrote [and I slightly edited, sorry]: $LANG is, or should be, a quick hack language. The fundamental feature of embedding application code directly in presentation markup is the biggest no-no there is. It leads to a poor (or non-existant) separation of concerns, typified by spaghetti code programs that are all but impossible to read, understand, extend and maintain. $LANG is quick, simple and easy to use and ideal for basic one or two page web hacks. But for building larger sites or dynamic web applications? Definately not! Alas, that's what most large dynamic web applications seem to be written in these days. Written by your average Joe who wouldn't know the difference between good programming and bad, and probably wouldn't care much about it if they did :-( Of course, the irony here is that, when talking to (say) Java people, this whole argument can get thrown back at Perl as well. Set $LANG to Perl and this could be a typical Perl is line noise boilerplate rant. Which would make this hypothetical post script -- PHP is just as bad for much the same reasons. Used by people who don't know any better and don't want to know any better. -- all the more ironic. As Greg said, certain things (PM groups, YAPC, etc) have brought a level of professionalism to Perl that maybe wasn't there before, but still -- these kind of accusations are still made all the time, and as long as there is prominent bad Perl code out there (I'm trying to avoid saying Matt Wright's name but whoops it just spilled out) accusations like this will continue to be made, and not without foundation. Thrown stones, glass houses, etc. I find it ironic to hear Perl hackers saying these sorts of things about PHP. If quick, simple and easy to use is such a crime, why are you using Perl? I mean, I realize I'm not being entirely fair here -- I know that many or most of the members of this list are much more disciplined than that -- but still, the essential qualities that you're objecting to are ones that for a long time have defined Perl Perl Culture. So what's the dividing line? When is it nice to be a quick hack language that's simple and easy, when does that lead to the biggest no-no there is? -- Chris Devers[EMAIL PROTECTED] Usenet is a co-operative venture, backed by nasty people. Follow the standards. -- Chris Rovers, in the Monastery
Re: php irony, was Re: webmail
Chris Devers wrote: When is it nice to be a quick hack language that's simple and easy, when does that lead to the biggest no-no there is? Simple and easy quick hack languages are great. I've got nothing against PHP or Perl in that respect. But for larger projects that you want to be scalable, adaptable, easy to customise and maintain, the first rule, or one of the first rules is to separate application code from presentation code. In Perl, Ruby, Python or Java, you can choose to be lax and hacky or strict and structured. You can apply the best technique as the situation demands it. In PHP you don't get that choice. It's like you're always stuck in lax and hacky mode. For that reason, I wouldn't recommend it for larger projects any more than I would receomment Perl 4. That's not to say that people haven't written large and high quality systems in Perl 4 or PHP, but I would suggest that they're the exceptions rather than the norms. A
Re: webmail
On Wed, Oct 30, 2002 at 04:38:12PM -0500, Chris Devers wrote: On Wed, 30 Oct 2002, everyone wrote: PHP is crap http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm http://developers.slashdot.org/article.pl?sid=02/10/29/2052239 Erek Dyskant writes Yahoo has decided to switch from a proprietary system written in C/C++ to PHP for their backend scripting. Here's the notes from a presentation by a Yahoo engineer at PHP Con 2002. While I mostly agree with all the anti-PHP arguments, the Yahoo presentation makes a pretty good case as well. Any responses from those that are so vigorously ripping up the PHP straw man (which, after all, it is -- this isn't london.phpm, is it)? Except for one part that I find curious. The presentation lists one of the cons for perl as poor sandboxing, easy to screw up server yet I get the feeling that that is the arguments against PHP. Or am I confusing the idea of screwing up namespaces with screwing things up between processes? Nicholas Clark
Re: webmail
http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm http://developers.slashdot.org/article.pl?sid=02/10/29/2052239 At 13:37 31/10/02, Nicholas Clark wrote: Except for one part that I find curious. The presentation lists one of the cons for perl as poor sandboxing, easy to screw up server I know of one large bank which does not support mod_perl because it believes some of its website users might mess up other users on the same boxes. They use perl cgi instead :-) I think I better learn PHP if for no better reason than to prepare for the mass PHP to perl/java conversions when people realise that PHP is a bad idea. And if they don't come around to thinking PHP is a bad idea, then well I will have just learnt PHP anyway Alex Openweb Analysts Ltd, London. Software For Complex Websites http://www.OWAL.co.uk/ Open Source Software Companies please register here http://www.OWAL.co.uk/oss_support/
Re: webmail
Nicholas Clark wrote: Except for one part that I find curious. The presentation lists one of the cons for perl as poor sandboxing, easy to screw up server yet I get the feeling that that is the arguments against PHP. Or am I confusing the idea of screwing up namespaces with screwing things up Well, from what I've seen, Apache/mod_perl stuff does not come with things that protect against quasi-infinite loops, or infinite memory bloat. You can put some of these in - BSD::Resource and Apache::SizeLimit, for example - but you have to pick them, install them, and test them. mod_perl, if it does run out of memory (ie, hits its hard limit), has frequently responded (in the past) by jibbering infinitely into the error log, until you run out of disk space, at which point you find a puzzled sysadmin who has missed the Out of memory! in the error log hidden by all the jibber. Even if it worked properly, this would leave you with little idea that anything had gone wrong, or what had gone wrong. I don't know whether PHP would behave any more gracefully. Cheers -- Tim Sweetman | http://www.thebunker.net/ A L Digital | eXistenZ is _PAUSED_!!! *splat* --- eXistenZ
Re: webmail
Nicholas Clark wrote: Except for one part that I find curious. The presentation lists one of the cons for perl as poor sandboxing, easy to screw up server yet I get the feeling that that is the arguments against PHP. Or am I confusing the idea of screwing up namespaces with screwing things up between processes? One problem I'm only too aware of is that mod_perl doesn't let you have different versions of modules installed into different vhosts. We have a bunch of SEMANTICO::* modules and an apache with 4 vhosts. Consequently, we have to be extremely careful when changing those SEMANTICO::* modules so we don't change any interfaces. It's doable, but it's not as convenient as per-vhost sandboxes. If that's what PHP offers[1]. -Dom [1] Never used php past a test page consisting of a single phpinfo() call. :-) -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: webmail
On Thu, 31 Oct 2002, Tim Sweetman wrote:
I don't know whether PHP would behave any more gracefully.
Is dumping core considered graceful?
S.
--
Shevek
I am the Borg.
sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print$x\n;eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;{$x}(\$x);};};}
foreach my $i (3..65535) { {'2'}($i); }
Re: webmail
On Thu, 31 Oct 2002, Alex McLintock wrote: I think I better learn PHP if for no better reason than to prepare for the mass PHP to perl/java conversions when people realise that PHP is a bad idea. I learnt enough PHP to install and use a non-core module, and get that, and database access, and cookies to interact. I'm certainly no uberprogrammer, and figured that our php programming lot could modify it and make it 'more PHPish' But no, my ropey first attempt is seemingly as well structured as it gets. I think it needs a big change, like that from perl 4 to 5, to introduce namespaces and better scoping in general. Also, despite my experience, it was claimed that adding in more modules is a pain - I can see that you'd have to recompile, link and then restart the webserver, but that shouldn't be challenging. But what perl modules give is a middle way between compiled-in and include()d files. Possibly what php is most missing is widespread usage for non-cgi stuff, and with it, the programming experience of programmers taught to program, rather than web or internet geeks, taught to do what's necessary to get something working. the hatter
Re: webmail
On Wed, Oct 30, 2002 at 10:08:42PM +, Tim Sweetman wrote: For spaghetti avoidance, the right thing tends to constitute nonspaghetti; separating stuff out; abstraction layers; passing the right data, and just the right data, to another part of the system through a comprehensible interface. Yep, and all that's possible with my little toy system. It doesn't force it, true, but even so, if it results in spaghetti that's the user's fault, as it is trivial to avoid. Firstly: Trivial templates by variable substitution is not an intuitive thing to do. The only intuitive interface is the nipple. Although I imagine a good stout club is up there with it. Sadly, we're talking about computers. I'm doing it here, because DC did it earlier, because in a sense it removes content from presentation. However, a bunch of variables isn't something that you can (without heavy wizardry) simply pass somewhere else. You could pass each variable individually: my ($width, $height, $iq, $motherfuckers_per_second, $foo, $bar, $blarch) = $slimshady-vital_stats; Eeuuuwww. I'd refer to the slimshady-width accessor method when I needed to spew the width to the output. Remember, I'm abstracting application logic out from the presentation. slimshady would be an instance of the Musician::Allegedly class, defined outside the template and wrapped up in easy-to-reuse-and-not-tied-to-the-web-at-all goodness. Secondly: Except for trivial amounts of data, slinging data around in hashes, hash references, list references etc is good for this sort of application. Welcome to the world of objects :-) Trivial templates by variable substitution does not make this particularly easy. Templating systems (well, TT and H::T) _do_. In that case I guess that phtml isn't trivial in your view. Personally, I *do* think it's trivial, cos the implementation is only a few lines of simple code and a couple of lines in the apache config. I don't see why people make such a song and dance about this stuff. Separating templates out also means it's easier to change appearance without changing functionality. As I have, in fact, done on a site using my system. It reduces friction between specialised graphic designers and coders. It keeps dreamweaver and emacs relatively happy. Graphics designers, dreamweaver and emacs are of no interest to me, but they wouldn't find my toy intolerable. Let me clear up a few things here. I wrote my toy system because I had an itch which needed scratching. I looked at pre-existing alternatives and rejected them all for various reasons. The only reason I'm even bothering to argue about this is because of the incorrect assertions coming from people who really should know better that my sort of solution inevitably leads to spaghetti code and all the rest of the nastiness from Revelations. If there's anyone here looking for a solution to their problem, I don't want them to only hear the solution that I consider to be horribly over- engineered. And I certainly don't want them to reject potential solutions based upon misinformation. It makes it easier to grep your source without running into fragments of HTML-or-whatever. So isn't it a good thing that I don't have that problem! I rock SO hard. All of which are good things in general, rather than spaghetti avoidance features in particular, and which go away if you start having Perl-like bits in your templates. No, they do not. They *can* go away *if* the user is an idiot. But would you let an idiot loose in your templates? If your graphics designer is messing around in the bits he's specifically been told not to mess with, then HE is the problem. If your HTML coders are too dense to understand the few simple constructs they might need - like looping - then THEY are the problem, and they can be easily replaced by out-of-work perl mongers. OK. You maintain that: *any* templating language is code embedded in presentation Yup, if it's to let you do anything useful like dynamically build a visual representation of a table of data. Loosely speaking, when we talk about code, we mean stuff that can do some of these: 1. implement an arbitrary algorithm 2. loop for an arbitrary period. Perhaps forever. Perhaps not. 3. perhaps do IO, perhaps system calls. 4. perhaps invoke your methods elsewhere within your system. That list looks remarkably like it's been designed ex post facto to rule me out. I say that anything you write to tell the computer what to do is code. Turning data structures into nicely formatted tables counts. Some choose to invent a new language to do it in, whereas I was lazy and impatient and used someone elses which, tbh, does a far better job than I could in any reasonable time frame if I tried to create my own.. A good language makes it easy to do what you're trying to do. OO languages make certain kinds of useful
Re: webmail
On Wed, Oct 30, 2002 at 10:52:06PM +, Lusercop wrote: On Wed, Oct 30, 2002 at 02:07:12PM +, David Cantrell wrote: Remember, all software sucks*. But to say that embedding application code in markup leads to a poor (or non-existant) seperation of concerned, typified by spaghetti code is to talk bollocks. * - and absolutism in software sucks absolutely? Erm. I'm afraid I don't agree, please explain how embedding application code in page rendering information can *not* lead to a lack of separation between the two. I would argue that seeing that the presentation is part of the application, then the code in the presentation is part of the application code. This is regrettable, but unavoidable. It should of course be kept to a minimum. But you'll do that anyway so that you can have interchangeable interfaces such as a web interface and a curses interface. Seperate the heavy lifting from the presentation by all means. That's a Good Thing. I'm not quite sure what your definition of spaghetti code is. But I include in mine: chasing all over for the file containing the relevant module/method/ function definition. Oh well in that case, any use of modules is spaghetti. There's at least six different places that I might find perl modules on this 'ere machine, with a completely stock installation of perl 5.6.1. As I've argued above, I think your starting point, that it's possible to write non-spaghetti embedded templates is actually flawed, due to what I consider to be spaghetti code. Your definition would seem to be flawed, as above, and would in fact lead to the conclusion that introducing what seperation we can between logic and presentation is a bad thing. In your examples, such things as where does this hash get initialised are important, and are then spaghetti in terms of following them. It was a trivial snippet, not a full application. I can't be bothered to post a full application, which would show the data coming from elsewhere. What Tim is saying, and FWIW, I think I agree with him on this, is use the right tool for the job. Excellent. My problem is that the business logic gives me this 'ere data structure, and it needs to be displayed prettily. I know, I'll use the Practical Extraction and Reporting Language. Sounds like the ideal tool for the job. It's very easy to say well, my way solves the problem of chopping up the carrots, and it does, however, it's not in the long term the best way of doing things. In the same way, using a templating system which properly separates code and data will help you in the long run, though it be more effort in the short, but you will get yourself into trouble if you don't. Actually, I don't recall it being any effort in the short term either. Creating the tiny templating system was no more work than a simple CGI of the same sort of size. FWIW, it's 49 lines of code, including comments, and is not limited to HTML. -- Grand Inquisitor Reverend David Cantrell | http://www.cantrell.org.uk/david Considering the number of wheels Microsoft has found reason to invent, one never ceases to be baffled by the minuscule number whose shape even vaguely resembles a circle. -- anon, on Usenet
Re: webmail
David Cantrell wrote: Let me clear up a few things here. I wrote my toy system because I had an itch which needed scratching. I looked at pre-existing alternatives and rejected them all for various reasons. The only reason I'm even bothering to argue about this is because of the incorrect assertions coming from people who really should know better that my sort of solution inevitably leads to spaghetti code ... So everyone else thinks that templating systems are a good idea. So do you, but yours is smaller. Much discussion ensues - probably boundless - about exactly what the template system should, or shouldn't be able to do... Your lightweight system is neither obvious, nor what any nonidiot would do, nor necessarily trivial in any other nonCOBOL, nonAssembler language, and therefore implicitly suggests Perl (or similar) and a templating scheme rather like yours. And is not what everyone else was saying would cause spaghetti code. You could mount similar arguments on virtually anything. Get rid of $W==1 or strict, and you (and any other nonidiot) will do the right thing anyway. Sure. Get rid of RDBMSs, and just store your data in delimited, table-like files! It'll work. Doesn't *have* to lead to spaghetti... Cheers Ti'
Re: webmail
Shevek wrote: On Thu, 31 Oct 2002, Tim Sweetman wrote: I don't know whether PHP would behave any more gracefully. Is dumping core considered graceful? Compared with slurping memory forever or spitting to STDERR forever, yes, very. One can't really fault a very ill person from leaving a corpse. I feel that if they wander around zombielike attacking the living, one has a legitimate grievance. Cheers Ti'
Re: webmail
Dave Cross wrote: Module naming is very important. I wonder how many other people have been put off using HTML::Template because they aren't building HTML with their templates? I always thought the name related to the fact that the embedded tags are designed to look just like HTML tags. You can generate non-HTML, text but you have to use HTML-like tags to do it. Personally, I think this is all wrong. I want my template tags to stand out against the background, not blend into it. But the HTML::Template docs seem to imply that this is a positive feature becuase HTML designers are already familiar with HTML tags. I guess we all have different opinions about what's right and wrong[*]. A [*] but I actually think I am right on this matter[+] [+] but I could be wrong about that...
Re: webmail
Lusercop wrote: I think my conclusion for all of this is that I can't trust PHP, because architecturally, it appears to be designed for use in situations where the necessity is not for any kind of privilege management, or separation. It appears to be designed to get dynamic pages up and running as quickly as possible and as easily as possible. Absolutely. PHP is, or should be, a quick hack language. The fundamental feature of embedding application code directly in presentation markup is the biggest no-no there is. It leads to a poor (or non-existant) separation of concerns, typified by spaghetti code programs that are all but impossible to read, understand, extend and maintain. PHP is quick, simple and easy to use and ideal for basic one or two page web hacks. But for building larger sites or dynamic web applications? Definately not! Alas, that's what most large dynamic web applications seem to be written in these days. Written by your average Joe who wouldn't know the difference between good programming and bad, and probably wouldn't care much about it if they did :-( ASP is just as bad for much the same reasons. Used by people who don't know any better and don't want to know any better. A
Re: webmail
On Wed, Oct 30, 2002 at 10:26:41AM +, Andy Wardley wrote: ASP is just as bad for much the same reasons. Used by people who don't know any better and don't want to know any better. That latter is what's so important. :-( And of course, it devalues the skills of those who do know better. :-/ The Lusercop has watched the company he works for shrinking slowly, and is now wondering when his job will have to go as a result. Andy, I notice you said nothing about the naked wrestling. :-) -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: webmail
Chisel Wright wrote: On Wed, Oct 30, 2002 at 10:17:12AM +, Andy Wardley wrote: I always thought the name related to the fact that the embedded tags are designed to look just like HTML tags. You can generate non-HTML, text but you have to use HTML-like tags to do it. I haven't tried, but IIRC you can actually use the H::T filter option to deal with (almost) any tag format you like. As I understand it, _the_ key difference between H::T and the other templating systems available, is flow of control and data. The other templating systems call Stuff, and generate content. H::T takes data from your code, and generates output. H::T has a straightforward, linear flow of data FROM your application THROUGH H::T TO the output data. Data and control hop around, with other templating systems, which can be more powerful, therefore more dangerous. How to make tags which stand out enough, but not too much, and are easy to edit etc, probably depends on what systems you're using (but H::T can cope with most of them). That's not, IMO, the important bit (and not worth mudwrestling over). -- Tim Sweetman | http://www.thebunker.net/ A L Digital | *squeak* --- Kate Bush, Withering Hertz
Re: webmail
Tim Sweetman wrote: As I understand it, _the_ key difference between H::T and the other templating systems available, is flow of control and data. No, one of the key difference is that H::T *enforces* that model. With TT (and others) it's optional. Sometimes I use TT very strictly, and sometimes I use it for quick hacks. I prefer to have the choice, as well as the the inherent responsibility that comes with that. I don't want the designer of my template system (even if that person is me) thinking that he knows best about every possible situation in which I might use that tool. Pragmatism not dogmatism. (and not worth mudwrestling over). There are few things in life that aren't worth mud wrestling over. :-) A
Re: webmail
Randal L. Schwartz wrote: I believe XML is great for what it was intended: a cross-platform vendor-neutral text-based representation of hierarchical somewhat-self-describing data, somewhat robust to version upgrade. However, I hate typing it. I hate having to type /foo when I get to the ending level. I want to just type a right-paren, watch my editor flash the corresponding left paren, and be done with it. Sounds like you need AML - Andy's/Amazing/Abstract/Another/Arsecrack Markup Language. It's like XML, but not quite. It's also like Lisp, but not quite, It's also like, nearly finished, but not quite. XML: titleblah blah/title AML: title:blah blah XML: quoteAll template languages are blinkgay/blink/quote AML: quote:All template languages are blink:gay XML: bibold and italic/i/b AML: b i:bold and italic XML: lt; silly br/ entities amp; blah gt; AML: lt silly br entities blah gt I started writing it because, like you, I hate writing XML. Too much verbosity and itty-bitty-get-everything-in-exactly-the-right-place nonsense. So I devised a stripped-down XML meta-syntax which is easier for humans to read and write, and a tool to compile it into XML or whatever. The other important thing about AML is that it's a dynamic language. You can reference parts of the document object model directly from within the document. No messing around with separate DOM tools or XSLT to make your document do what you want. Example: module: name:My Funky Module version:3.14 author: name:Andy Wardley email:[EMAIL PROTECTED] about: This module is called name (or I can also reference it as module.name) and it is at version version and written by author.name (author.email). I'll get around to finishing it one of these days. Just haven't got any time for it right now. A
Re: webmail
On Wed, Oct 30, 2002 at 01:09:51PM +, Tim Sweetman wrote: reductio ad=absurdum ... so we might as well all program in COBOL. /reductio That's not reductio ad absurdum, there's nothing absurd about programming in cobol. Oh, wait -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: webmail
On Wed, Oct 30, 2002 at 01:09:51PM +, Tim Sweetman wrote: David Cantrell wrote: On Wed, Oct 30, 2002 at 10:26:41AM +, Andy Wardley wrote: PHP is, or should be, a quick hack language. The fundamental feature of embedding application code directly in presentation markup is the biggest no-no there is. It leads to a poor (or non-existant) separation of concerns, typified by spaghetti code programs that are all but impossible to read, understand, extend and maintain. Unreadable spaghetti is a function of the programmer, not (generally) of the language. reductio ad=absurdum ... so we might as well all program in COBOL. /reductio There are, of course, other reasons for rejecting languages. Some of which apply to PHP. Some of which apply to perl, TT, COBOL and any other flavour of the week. Remember, all software sucks*. But to say that embedding application code in markup leads to a poor (or non-existant) seperation of concerned, typified by spaghetti code is to talk bollocks. Yes, there are *some* languages which might be said to encourage spaghetti. Assemblers do, as do many dialects of BASIC. But I see nothing inherent in embedding code in markup that would encourage it**. Therefore, when you *do* come across such 'orribleness, and especially if it's in a language where spaghetti can be easily avoided then the programmer is most definitely to blame. * - and absolutism in software sucks absolutely? ** - depending on the lnaguage, of course. Embedded perl is fine, embedded Sparc assembler would suck. And I maintain that *any* templating language is code embedded in presentation. We can chop carrots finely with a food processor. Or we can duck out of the way and throw 15,000 knives across the room at high speed. I fail to see the point of this analogy. If you disagree with me, say so, and tell us why you think I'm talking arse. -- David Cantrell | Member of the Brute Squad | http://www.cantrell.org.uk/david One person can change the world, but most of the time they shouldn't -- Marge Simpson
Re: webmail
On 30 Oct 2002, Randal L. Schwartz wrote:
[%
FOR key IN hash.keys
%]
tr
tdem[% key %]:/em/td
td[% hash.key %]/td
/tr
[%
END
%]
You seem to be reinventing Mason, with a slightly different syntax
As a Mason user, I see a major difference here in that it is not clear
which of the [% %] blocks are designed to output and which are flow
control. Mason explicitly uses % % for outputting values and %perl or
a line starting with a % for procedural control. I think that this is
an important issue.
(perl .. /perl, instead of % .. %). And that's why I hate Mason
now. There's no mini-language that I can teach a non-Perl-head to
Pick a subset of Perl and teach only that? Why do you have to translate
everything to uppercase in order to pick out a subset?
help me with my pages. They must be exposed to ALL OF PERL for
anything non-trivial. Ugh.
S.
--
Shevek
I am the Borg.
sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print$x\n;eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;{$x}(\$x);};};}
foreach my $i (3..65535) { {'2'}($i); }
Re: webmail
David Cantrell wrote: But to say that embedding application code in markup leads to a poor (or non-existant) seperation of concerned, typified by spaghetti code is to talk bollocks. Looks like I'm talking bollocks then. :-) A Ignorant in bliss.
Re: webmail
David == David Cantrell [EMAIL PROTECTED] writes:
David Here's how you'd display a perl hash as an HTML table ...
David table
David tr
David thkey/th
David thvalue/th
David /tr
David perl
David foreach my $key (%hash) {
David /perl
David tr
David tdemperlprint $key/perl:/em/td
David tdperlprint $hash{$key}/perl/td
David /tr
David perl
David }
David /perl
David /table
In TT, that'd be
table
tr
thkey/th
thvalue/th
/tr
[%
FOR key IN hash.keys
%]
tr
tdem[% key %]:/em/td
td[% hash.key %]/td
/tr
[%
END
%]
/table
I find that much easier to read. And I can even explain it (mostly :-)
to someone who doesn't know Perl.
You seem to be reinventing Mason, with a slightly different syntax
(perl .. /perl, instead of % .. %). And that's why I hate Mason
now. There's no mini-language that I can teach a non-Perl-head to
help me with my pages. They must be exposed to ALL OF PERL for
anything non-trivial. Ugh.
David Yes, you're right, I never got round to interpolating variables directly
David into the HTML, but that would be REALLY trivial to add in, and I'll do it
David if the lack of it annoys me enough. This is no different from the way
David it would be done in any other templating system, the one difference being
David that I was too lazy to invent my own little language and decided to use
David perl instead.
But it's *s* close to Mason. Use that. Stop trying harder. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: webmail
On Wed, 30 Oct 2002, everyone wrote: PHP is crap http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm http://developers.slashdot.org/article.pl?sid=02/10/29/2052239 Erek Dyskant writes Yahoo has decided to switch from a proprietary system written in C/C++ to PHP for their backend scripting. Here's the notes from a presentation by a Yahoo engineer at PHP Con 2002. While I mostly agree with all the anti-PHP arguments, the Yahoo presentation makes a pretty good case as well. Any responses from those that are so vigorously ripping up the PHP straw man (which, after all, it is -- this isn't london.phpm, is it)? -- Chris Devers[EMAIL PROTECTED]
Re: webmail
On Wednesday, October 30, 2002, at 04:14 pm, Randal L. Schwartz wrote: Andy == Andy Wardley [EMAIL PROTECTED] writes: Andy I started writing it because, like you, I hate writing XML. Too much Andy verbosity and itty-bitty-get-everything-in-exactly-the-right-place Andy nonsense. So I devised a stripped-down XML meta-syntax which is easier Andy for humans to read and write, and a tool to compile it into XML or Andy whatever. Dude, if you don't stop inventing languages, I'm gonna have to start calling you meta-Andy. :) This is cool. Have you seen the LISP-XML? S [snip] You might also want to take a look at YAML http://yaml.org/ - there's a YAML.pm already in CPAN. SOX http://www.langdale.com.au/SOX/ and SLiP http://www.scottsweeney.com/projects/slip are also interesting. They're alternate XML syntaxes that use indentation (Python anyone) Cheers, Adrian (apparently alone in actually quite liking XMLs closing tags :-)
Re: webmail
David Cantrell wrote:
On Wed, Oct 30, 2002 at 01:09:51PM +, Tim Sweetman wrote:
David Cantrell wrote:
On Wed, Oct 30, 2002 at 10:26:41AM +, Andy Wardley wrote:
PHP is, or should be, a quick hack language. The fundamental feature
of embedding application code directly in presentation markup is the
biggest no-no there is. It leads to a poor (or non-existant) separation
of concerns, typified by spaghetti code programs that are all but impossible
to read, understand, extend and maintain.
Unreadable spaghetti is a function of the programmer, not (generally) of
the language.
reductio ad=absurdum
... so we might as well all program in COBOL.
/reductio
There are, of course, other reasons for rejecting languages. Some of which
apply to PHP. Some of which apply to perl, TT, COBOL and any other flavour
of the week.
Remember, all software sucks*. But to say that embedding application code
in markup leads to a poor (or non-existant) seperation of concerned,
typified by spaghetti code is to talk bollocks. Yes, there are *some*
languages which might be said to encourage spaghetti. Assemblers do, as do
many dialects of BASIC. But I see nothing inherent in embedding code in
markup that would encourage it**. Therefore, when you *do* come across such
'orribleness, and especially if it's in a language where spaghetti can be
easily avoided then the programmer is most definitely to blame.
* - and absolutism in software sucks absolutely?
** - depending on the lnaguage, of course. Embedded perl is fine, embedded
Sparc assembler would suck.
Languages (amongst other things) should make it easy to do the right
thing.
For spaghetti avoidance, the right thing tends to constitute
nonspaghetti; separating stuff out; abstraction layers; passing the
right data, and just the right data, to another part of the system
through a comprehensible interface.
# example with HTML::Template (not tried, so for example only)
$template-param($foo-RetrieveSomeDBStuff());
$template-param(my_name_is, $slimshady-random_nym);
print $template-output;
# example using trivial-templates-by-variable-substitution
my %data = $foo-RetrieveSomeDBStuff();
my $name = $slimshady-random_nym;
print
My name is (!) my name is (!) my name is (!) $name
Average expletives per song: $data{rude_words_per_song}
Disturbed teenage fans: $data{disturbed_teenage_fans}
...;
Firstly:
Trivial templates by variable substitution is not an intuitive thing
to do. I'm doing it here, because DC did it earlier, because in a sense
it removes content from presentation. However, a bunch of variables
isn't something that you can (without heavy wizardry) simply pass
somewhere else. You could pass each variable individually:
my ($width, $height, $iq, $motherfuckers_per_second, $foo, $bar,
$blarch) =
$slimshady-vital_stats;
... but that's a good way to get confused, it wrong, or RSI.
Secondly:
Except for trivial amounts of data, slinging data around in hashes, hash
references, list references etc is good for this sort of application.
You can then say things like
print Dumper(\%page_data)
or
$template-param(%page_data)
Trivial templates by variable substitution does not make this
particularly easy. Templating systems (well, TT and H::T) _do_. TtbVS
makes using globals for everything _very_ easy. Use them here, use them
there. Look, the data transfers over, simple...
Templating systems work well with interfaces that pass data.
Interpolation works well with everything sitting in variables. The
latter is more conducive to spaghetti code. Therefore, templating
systems (used like this) discourage spaghetti code.
(Natch, this relies on this kind of structure suiting your problem, and
your programmers - not to mention relying on spaghetti code actually
being a bad solution for this problem and these programmers, which seems
dangerous to assume. FWIW, _entirely_ unidirectional data flow from code
to template is often difficult or stupid. Should I throw all the scalar
data on slim shady that I have into the template, in case it turns out
to be needed? Should I list fields in the template somewhere? Should I
allow the template to go SlimShady.name?)
Separating templates out also means it's easier to change appearance
without changing functionality. It reduces friction between specialised
graphic designers and coders. It keeps dreamweaver and emacs relatively
happy. It makes it easier to grep your source without running into
fragments of HTML-or-whatever. All of which are good things in general,
rather than spaghetti avoidance features in particular, and which go
away if you start having Perl-like bits in your templates.
I fail to see the point of [magimix] analogy. If you disagree with me, say
so, and tell us why you think I'm talking arse.
OK. You maintain that:
*any* templating
language is code embedded in presentation
Loosely speaking, when we talk about code, we mean stuff that can do
some of
Re: webmail
Andy Wardley wrote: Sounds like you need AML - Andy's/Amazing/Abstract/Another/Arsecrack Markup Language. It's like XML, but not quite. It's also like Lisp, but not quite, It's also like, nearly finished, but not quite. XML: titleblah blah/title AML: title:blah blah Aw, you mean you're *serious*? First time I read this, I thought it was a brilliant spoof of the kind of abstraction-layer-for-something-else-that-won't-do-quite-everything-the-underlying-one-does, of which a hundred dead instances lie motionless in CPAN's catacombs. :) Enough of that sort of thing and, as one of my ex-coworkers did, you start to use the words abstract and obscure interchangably. People start to develop abstraction resistance. 'Tis a problem. Cheers Ti'
Re: Webmail
On 30 Oct 2002, Dave Hodgkinson wrote:
does anyone have any recommendations for webmail that won't degenerate
into a templating argument?
Yeah, I'm impressed that in all this thread (over 100 messages?) I think
maybe one or two posts actually addressed the question. I was also looking
forward to an answer to this one. If Squirrelmail is bad because it's PHP
and $hand_rolled_with{$template} is even worse, then what doesn't suck?
I'd also like to set up such a thing, if any projects out there came
recommended highly enough. Apparently nothing is better than all of them?
--
Chris Devers[EMAIL PROTECTED]
Q: How many IBM CPU's does it take to do a logical right shift?
A: 33. 1 to hold the bits and 32 to push the register.
Re: webmail
On Wed, Oct 30, 2002 at 02:07:12PM +, David Cantrell wrote: Since noone else has really argued this, I'm going to rise to it, as to me, Cantrell obviously needs a good kick up the backside. Remember, all software sucks*. But to say that embedding application code in markup leads to a poor (or non-existant) seperation of concerned, typified by spaghetti code is to talk bollocks. * - and absolutism in software sucks absolutely? Erm. I'm afraid I don't agree, please explain how embedding application code in page rendering information can *not* lead to a lack of separation between the two. In my (possibly limited) experience, the lack of any rigorous controls of this separation, leads to the two getting tweaked to be closer and closer together until they merge. I'm afraid that I think your sentence above is more like talking bollocks (in the general case) than the opposite. Yes, there are *some* languages which might be said to encourage spaghetti. Assemblers do, as do many dialects of BASIC. Right. We're agreed on *something* then. But I see nothing inherent in embedding code in markup that would encourage it**. ** - depending on the lnaguage, of course. Embedded perl is fine, embedded Sparc assembler would suck. OK, what do you see as the qualitative difference between these two. By your own argument, the code and data are still separate, so you just start your code tags, put some assembler in, and then close them. Why is this in any way different to embedding say perl/python/VB? The point is that you're mixing things which oughtn't be mixed, thereby asking for multiple people with different skillsets to be dealing with (different bits of) the same data. If you've got webmonkeys who won't be touching code, why is putting sparc assembler in the bits they won't touch any different to putting perl (assume for the sake of this that all the code maintainers speak sparc assembler as fluently as we do perl). Basically you're asking for spaghetti code, because the code is separated. (common functionality will have to be included from *somewhere* after all). I'm not quite sure what your definition of spaghetti code is. But I include in mine: chasing all over for the file containing the relevant module/method/ function definition. I feel this is a simple product of embedding code in templates. If this isn't, then the alternative is that there are multiple copies of the code all over the place, (which probably all work in subtly different ways). Any sensible software engineer will tell you that this is a bad thing, and quite honestly, I think you of all people ought to know better. Therefore, when you *do* come across such 'orribleness, and especially if it's in a language where spaghetti can be easily avoided then the programmer is most definitely to blame. As I've argued above, I think your starting point, that it's possible to write non-spaghetti embedded templates is actually flawed, due to what I consider to be spaghetti code. In your examples, such things as where does this hash get initialised are important, and are then spaghetti in terms of following them. My point of view on this is that the programmer is to blame for not trying to properly separate out code and data in the first place. Embedding data in code is always going to be evil and bad and wrong. You want non-coders to be able to maintain the data. Any programmer who does mix the two unnecessarily is not worthy of the title. I dislike the term hacker in most software I write, because I think that the engineering and the future maintenance is extremely important. If you want to be a hacker, go for it, but don't claim that your code is designed for anything other than solving this problem now. If you want maintainable code, it is good practice to separate out your problem into multiple pieces. You simply cannot do that without proper templating, and any programmer worthy of the name would be trying to untangle said problem precisely so it doesn't turn into spaghetti. And I maintain that *any* templating language is code embedded in presentation. We can chop carrots finely with a food processor. Or we can duck out of the way and throw 15,000 knives across the room at high speed. I fail to see the point of this analogy. If you disagree with me, say so, and tell us why you think I'm talking arse. What Tim is saying, and FWIW, I think I agree with him on this, is use the right tool for the job. It's very easy to say well, my way solves the problem of chopping up the carrots, and it does, however, it's not in the long term the best way of doing things. In the same way, using a templating system which properly separates code and data will help you in the long run, though it be more effort in the short, but you will get yourself into trouble if you don't. He is disagreeing
Re: webmail
On Wed, Oct 30, 2002 at 10:22:17PM +, Tim Sweetman wrote: OK, so if/when they try and scale them up (and assuming you and I are onto something here, and PHP _is_ harder to build big systems in) You ought to know better than to post this! (especially this week). -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: Webmail
IMP is another popular PHP-based system. www.horde.org/imp If you can afford it and have control over the choice of mail server, I'd recommend looking at Samsung Contact. www.samsungcontact.com Their webmail is tightly integrated with the mail server via their own UAL API + Apache (no IMAP connection), but uses **TCL** for the templates. It's pretty lightweight despite that and you can change them. I keep thinking it's free for a smallish number of mailboxes, not sure. Amazingly, it does MAPI as well. This is the direct descendant of the HP OpenMail product and I quite like the look of it. Any other experiences of it would be appreciated. It's not open source, but does run on Linux. On 30 Oct 2002, Dave Hodgkinson wrote: does anyone have any recommendations for webmail that won't degenerate into a templating argument?
Re: webmail
Lusercop wrote: On Wed, Oct 30, 2002 at 02:07:12PM +, David Cantrell wrote: Since noone else has really argued this, I'm going to rise to it, as to me, Cantrell obviously needs a good kick up the backside. Grr. I _knew_ connecting my outgoing mail via IP-over-sloth was going to cause trouble... Ti'
Re: webmail
On 2002.10.30 08:14 Randal L. Schwartz wrote: It looked a bit ugly, but LISP *can be* ugly. This is true. Lisp is one of the few languages with an actual entitlement to ugliness. Randy -- --- Randy J. Ray | Men occasionally stumble over the truth, but most of them [EMAIL PROTECTED] | pick themselves up and hurry off as if nothing had happened. +1 650 930-9097 | -- Sir Winston Churchill
Re: Webmail
On Wed, Oct 30, 2002 at 10:38:23PM +, Dave Hodgkinson wrote: does anyone have any recommendations for webmail that won't degenerate into a templating argument? Needs to be seriously rewritten because of shonky coding, but the demo works and it seemed to have a reasonable feature set: http://webmail.omnis.ch/omail.pl?action=about I think it would take a couple of days to bring it in to line with reasonable coding practices and put the HTML into templates. Of course, as soon as you introduce template technology you make it impractical to run as a simple, honest CGI script[1]. -- Steve Keay [1] not really a templating argument?
Re: Webmail
- Original Message - From: Dave Hodgkinson [EMAIL PROTECTED] does anyone have any recommendations for webmail that won't degenerate into a templating argument? I'm going to ignore the PHP bashing and templating discussions and add that Horde and SquirrelMail are both recommened on the GLLUG list when ever this question comes up by a number of people. So while neither is written in Perl both are in use. If you have no major phobia of PHP then the gllug archives http://list.ftech.net/pipermail/gllug/ cover a lot of mail releated topics in the last few months including webmail, alternative email clients for Windows (Yes on a Linux list) securing IMAP and even making Outlook work with real IMAP (including shared folders) but the recommended solutions seem to be PHP based if for no other reason than they exist. Dean (My work runs Exchange, we pays our money and gets our webmail) -- Profanity is the one language all programmers understand --- Anon
Re: webmail
On Wed, Oct 30, 2002 at 04:38:12PM -0500, Chris Devers wrote: On Wed, 30 Oct 2002, everyone wrote: PHP is crap I don't think PHP is crap. I am also amused and puzzled at the people writing huge tracts on why PHP is crap while not at the same time acknowledging there are vastly more websites written in PHP doing useful things for lots of people than there are in perl -- witness the scrabbling to find even remotely interesting success story cases for Perl (what recent ones have there been?). I suspect more revenue is generated from PHP sites than Perl sites. As a corollary, there are less (by some metric) experienced people writing more web software in PHP than in Perl. PHP gets you sooo much more with the same amount of effort than with perl. PHP is fundamentally quite easy, the learning curve astonishingly flat. Hardly the case for perl. A very large application written in OO Perl with a decent MVC-supporting tech like TT would almost certainly be more extensible maintainable than one in PHP and enable a split between designer and coder, and more agility were the site to be completely re-skinned. However, the number of those such applications is I intuit very small. And besides, it is possible to put code shared by many pages into a single place with PHP and its (admittedly quite hacky) OO capabilities help. Separating code from presentation is an awfully fascinating and lofty goal for some folk but the fact is, for most people and sites it is more work that is basically unnecessary because of the size of the project. About every web tech project I've seen in the last five years has been do-able by two or three people at most. For those projects it is actually *less* readable and understandable to separate since the parts of the code that do stuff and then present it are further apart for no practical immediate benefit. Worse is better. It's a classic case of picking the tool for the job, and the person and the budgetary, political, development, social environment. Each has its merits in different circumstances. There is no solve-all solution (yet). Paul (who thinks that without Template Toolkit/Mason and mod_perl perl would be bordering on a waste of time for web applications, compared with technologies like PHP) -- Paul Makepeace ... http://paulm.com/ If my my mum likes cabbage, then mother wouldn't shave. -- http://paulm.com/toys/surrealism/
Re: Webmail
On Thu, Oct 31, 2002 at 12:49:12AM -, Dean Wilson wrote: but the recommended solutions seem to be PHP based if for no other reason than they exist. I think this is the best summary so far. Paul -- Paul Makepeace ... http://paulm.com/ If we were a fashionable pink, then feeble screebles. -- http://paulm.com/toys/surrealism/
Re: webmail
Paul == Paul Makepeace [EMAIL PROTECTED] writes: Paul I am also amused and puzzled at the people writing huge tracts on why Paul PHP is crap while not at the same time acknowledging there are vastly Paul more websites written in PHP doing useful things for lots of people than Paul there are in perl -- witness the scrabbling to find even remotely Paul interesting success story cases for Perl (what recent ones have there Paul been?). A lot of the ones at http://perl.apache.org/outstanding/success_stories/ seem recent. And I suppose you haven't heard of match.com or citysearch.com or ticketmaster.com before? Oh wait, you're a brit. :) Paul I suspect more revenue is generated from PHP sites than Perl Paul sites. I don't. I suspect PHP runs more hobby sites. I suspect Perl does more of the e-commerce heavy lifting and pretty-lifting. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: webmail
On Tue, Oct 29, 2002 at 12:55:22AM +0100, Paul Johnson wrote: When I looked and asked here a month or so ago there didn't seem an obvious choice. I wondered about acmemail and sparkle, but eventually went for SquirrelMail, which is written in php. I used to run it, but the security cost of having PHP on my server was too high (and SquirrelMail itself has had some security problems). One of these years I'll write a decent webmail system (i.e. one that doesn't depend on the client having JavaScript or cookies)... Roger
Re: webmail
On Mon, Oct 28, 2002 at 02:49:59PM -0800, Randal L. Schwartz wrote: I wish people would stop discovering Mason and discover TT instead. I wish people would stop discovering TT and discover HTML::Template instead. Each to their own I guess. :-) Chisel -- e: [EMAIL PROTECTED] | Eagles may soar, but weasels don't get w: www.herlpacker.co.uk | sucked into jet engines. gpg: D167E7FE |
Re: webmail
On Tue, Oct 29, 2002 at 09:15:15AM +, Chisel Wright ([EMAIL PROTECTED]) wrote: On Mon, Oct 28, 2002 at 02:49:59PM -0800, Randal L. Schwartz wrote: I wish people would stop discovering Mason and discover TT instead. I wish people would stop discovering TT and discover HTML::Template instead. Each to their own I guess. :-) Depends what you're doing I guess. At least half of what I do with templates has nothing at all to do with generating HTML so it makes no sense to use a templating system that is tied to producing HTML. (honestly not tryingto start a flamewar here) Dave... -- And crawling on the planet's face, some insects called the human race Lost in time, and lost in space. And meaning.
Re: webmail
On Tue, Oct 29, 2002 at 09:29:58AM +, the hatter wrote: suggestions. Maybe we should schedule a Mason vs TT footie match at YAPC, to decide which is superior. Footie? No. Mason vs TT vs HTML::Template Naked Wrestling. -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: webmail
On Tue, 29 Oct 2002, Lusercop wrote: On Tue, Oct 29, 2002 at 09:29:58AM +, the hatter wrote: suggestions. Maybe we should schedule a Mason vs TT footie match at YAPC, to decide which is superior. Footie? No. Mason vs TT vs HTML::Template Naked Wrestling. Do you have any particular template system advocates that you want to see naked, or should I just express general worry about what perl has done to your mind ? the hatter
Re: webmail
At 09:29 29/10/02, the hatter wrote: I wish people would stop writing tied-in templating systems, and define a meta-templating system so apps could easily be moved between templating systems. I'd say that XML and XSLT fits the bill. Alex Openweb Analysts Ltd, London. Software For Complex Websites http://www.OWAL.co.uk/ Open Source Software Companies please register here http://www.OWAL.co.uk/oss_support/
Re: webmail
Lusercop wrote: On Tue, Oct 29, 2002 at 09:29:58AM +, the hatter wrote: suggestions. Maybe we should schedule a Mason vs TT footie match at YAPC, to decide which is superior. Footie? No. Mason vs TT vs HTML::Template Naked Wrestling. N, I have been to a technical meeting, I know what you all look like! You just extended my therapy ;-) Will.
Re: webmail
On Tue, Oct 29, 2002 at 09:32:19AM +, Dave Cross wrote: Depends what you're doing I guess. At least half of what I do with templates has nothing at all to do with generating HTML so it makes no sense to use a templating system that is tied to producing HTML. I guess the name is misleading. I've used H::T for templating in general. I guess HTML was what it was originally intended to template, but it's not tied to it. (honestly not tryingto start a flamewar here) Personally I just had a yukky time with TT at work, so have an irrational dislike for it. Chisel -- e: [EMAIL PROTECTED] | Sackings will continue until morale w: www.herlpacker.co.uk | improves. gpg: D167E7FE |
Re: webmail
Dave Cross wrote about HTML::Template: At least half of what I do with templates has nothing at all to do with generating HTML so it makes no sense to use a templating system that is tied to producing HTML. I don't believe that HTML::Template _is_, in fact, tied to producing HTML. As far as I know, it doesn't add whitespace that you didn't specify or anything like that. Cheers -- Tim Sweetman | http://www.thebunker.net/ A L Digital | The geese flying in formation honk to encourage those up front to keep up their speed --- http://www.karinya.com/geese.htm
Re: webmail
On Tue, Oct 29, 2002 at 09:47:50AM +, the hatter wrote: On Tue, 29 Oct 2002, Lusercop wrote: Mason vs TT vs HTML::Template Naked Wrestling. Do you have any particular template system advocates that you want to see naked, or should I just express general worry about what perl has done to your mind ? I don't care who, as long as I get to punch their teeth down their throats. FUCK OFF WITH YOUR TEMPLATES. FUCK OFF UP YOUR STUPID ARSES. -- David Cantrell|Reprobate|http://www.cantrell.org.uk/david There seems to be something wrong with our ships today -- Rear-admiral Sir David Beatty, on seeing the Queen Mary and the Indefatigable destroyed at the Battle of Jutland
Re: webmail
On Tue, Oct 29, 2002 at 09:47:50AM +, the hatter wrote: Do you have any particular template system advocates that you want to see naked, or should I just express general worry about what perl has done to your mind ? It was more that this seems to be the way of settling disputes in the Perl world these days. I guess you could therefore infer the latter of your answers. -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: webmail
On Tue, Oct 29, 2002 at 09:29:58AM +, the hatter wrote: On Tue, 29 Oct 2002, Chisel Wright wrote: suggestions. Maybe we should schedule a Mason vs TT footie match at YAPC, to decide which is superior. no strict; print pSince all real programmers know that blinkall templating\n; print systems are gay/blink it might be considered fruitless to\n; print argue over which one is better./p\n;
Re: webmail
On Tue, Oct 29, 2002 at 09:57:48AM +, Alex McLintock wrote: At 09:29 29/10/02, the hatter wrote: I wish people would stop writing tied-in templating systems, and define a meta-templating system so apps could easily be moved between templating systems. I'd say that XML and XSLT fits the bill. And I'd say bwahahahaha. Seriously, though. I've experienced such enormous slowness and lack of scalability with XSLT that I couldn't really consider using it for production systems at the moment. Call me old school, but I think I want a thing which is doing some sort of transformation to some sort of output stream to, well, be written in a proper programming language, rather than go through all the hoops and massive verboseness of something like XSLT. I am a bit of an XML bigot, though. However, I've just started looking at XPFE and Mozillas framework stuff, and despite a few minor annoyances so far, it looks like it might help cure my XMLophobia a bit. Ben
Re: webmail
On Tue, 29 Oct 2002, Steve Keay wrote: no strict; print pSince all real programmers know that blinkall templating\n; print systems are gay/blink it might be considered fruitless to\n; print argue over which one is better./p\n; That'll be mr cantrell and mr keay vs whoever wins the template system heat - I want a fair fight guys, well-documented code, no unnecessary golf, the winner is determined by knockout, submission, or by rendering a template which shows how to write templates, without using 5 escape characters in a row. the hatter
Re: webmail
On Tue, Oct 29, 2002 at 12:01:59PM +, the hatter wrote: That'll be mr cantrell and mr keay vs whoever wins the template system heat - I want a fair fight guys, well-documented code, no unnecessary golf, the winner is determined by knockout, submission, or by rendering a template which shows how to write templates, without using 5 escape characters in a row. Aaaarhhh, the memories, the memories! In a previous life, I had to hack with Storyserver. tcl is BAD. Anyway, one of my frobnitzes wasn't working, so I emailed supportvignette and they told me to keep doubling the number of escape characters until it works. It did work. With THIRTY-TWO of the little bastards. You had to double the number of escape characters for every level of nesting in your code. This made it completely impossible to factor out large chunks of common code into modules which might be used at various different nesting levels. To be fair, I believe this was a bug in their implementation of tcl and not in tcl itself, but even so, I won't touch that foul, accursed tongue again. And ph3ar my l33t brick-text skillz! -- David Cantrell|Reprobate|http://www.cantrell.org.uk/david One person can change the world, but most of the time they shouldn't -- Marge Simpson
Re: webmail
On Tue, Oct 29, 2002 at 08:32:31AM +, Roger Burton West wrote: I used to run it, but the security cost of having PHP What security cost? Paul -- Paul Makepeace ... http://paulm.com/ What is inside myself? Too true. -- http://paulm.com/toys/surrealism/
Re: webmail
On Tue, Oct 29, 2002 at 12:29:22PM +, Paul Makepeace wrote: On Tue, Oct 29, 2002 at 08:32:31AM +, Roger Burton West wrote: I used to run it, but the security cost of having PHP What security cost? Erm, you do read BUGTRAQ? Even if the only PHP code allowed on the system is Squirrelmail, it's still a pain to have to take down webmail every few weeks while they code round a function that was thought to be safe. Roger
Re: webmail
David == David Cantrell [EMAIL PROTECTED] writes: David In a previous life, I had to hack with Storyserver. tcl is David BAD. Anyway, one of my frobnitzes wasn't working, so I emailed David support@vignette and they told me to keep doubling the number David of escape characters until it works. It did work. With David THIRTY-TWO of the little bastards. Shades of troff, all over again! David You had to double the number of escape characters for every David level of nesting in your code. This made it completely David impossible to factor out large chunks of common code into David modules which might be used at various different nesting David levels. To be fair, I believe this was a bug in their David implementation of tcl and not in tcl itself, but even so, I David won't touch that foul, accursed tongue again. And ph3ar my David l33t brick-text skillz! No, it's a fault of troff, and shell, and TCL, and languages which confuse the level with the meta-level too easily. It was this madness which Larry avoided with Perl having only one level (or two levels, in interpolated regexen) of interpretation at most. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: webmail
On Tue, Oct 29, 2002 at 12:52:57PM +, Roger Burton West wrote: On Tue, Oct 29, 2002 at 12:29:22PM +, Paul Makepeace wrote: On Tue, Oct 29, 2002 at 08:32:31AM +, Roger Burton West wrote: I used to run it, but the security cost of having PHP What security cost? Erm, you do read BUGTRAQ? Not regularly, but enough to know that most of what is reported is of little practical consequence to most people. These days I rely on Debian's security advisories. The only serious advisory in the last couple of years was in March with the file upload bug. By serious, I don't consider being able to futz with mail() while in PHP's safe_mode by an authenticated user serious. Some might, of course. (Those people are unlikely to even use perl in those cases, period.) Even if the only PHP code allowed on the system is Squirrelmail, it's still a pain to have to take down webmail every few weeks while they code round a function that was thought to be safe. I'd read this as FUD, frankly, until you can show PHP has suffered vulnerabilities so severe as to require shutting down service every few weeks. This might seem anal of me but people might actually take what you're saying to heart and then continue to spread disinformation. If a package deserves commentary like that (say MS not fixing reported bugs for after several weeks of being notified), fair enough, if it doesn't, it's worth IMO avoiding hyperbole. SFOnline author Jon Lasser discusses over-zealous reporting, http://online.securityfocus.com/columnists/114 Paul -- Paul Makepeace ... http://paulm.com/ If you believe you are one of the gods, then crash the plane. -- http://paulm.com/toys/surrealism/
Security of PHP (was Re: webmail)
On or about Tue, Oct 29, 2002 at 03:35:22PM +, Paul Makepeace typed: I'd read this as FUD, frankly, until you can show PHP has suffered vulnerabilities so severe as to require shutting down service every few weeks. I'm a professional. I test posted exploits against (and from!) isolated, sacrificial systems before I pay much attention to them. I have found, particularly in the last six months, that PHP has a higher rate of usable exploits (which, to me, means external users are able to use the box in a way I disapprove of - shell functions, open relay, etc.) than any other service I'd contemplate running. So now I don't have it on my servers, and I advise other people that it's going to be a significant administrative burden. Roger
Re: webmail
Ben == Ben [EMAIL PROTECTED] writes: Ben I am a bit of an XML bigot, though. However, I've just started Ben looking at XPFE and Mozillas framework stuff, and despite a few Ben minor annoyances so far, it looks like it might help cure my Ben XMLophobia a bit. I believe XML is great for what it was intended: a cross-platform vendor-neutral text-based representation of hierarchical somewhat-self-describing data, somewhat robust to version upgrade. However, I hate typing it. I hate having to type /foo when I get to the ending level. I want to just type a right-paren, watch my editor flash the corresponding left paren, and be done with it. XML is great for machine-to-machine. For me, XML sucks for human-to-machine, and is only marginally better at machine-to-human. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: webmail
On Tue, Oct 29, 2002 at 03:35:22PM +, Paul Makepeace wrote: I'd read this as FUD, frankly, until you can show PHP has suffered vulnerabilities so severe as to require shutting down service every few weeks. This might seem anal of me but people might actually take what you're saying to heart and then continue to spread disinformation. If a package deserves commentary like that (say MS not fixing reported bugs for after several weeks of being notified), fair enough, if it doesn't, it's worth IMO avoiding hyperbole. I read what you're saying, and I'm unlikely to support PHP on my server for similar reasons to Roger. Chris Andrews, who reads this list[1], can probably explain better, as he has to deal with user support for PHP. In essence, however, it seems to be very easy to write PHP in a way that it silently eats errors, fails to quote appropriately, and other such things, and much harder to write PHP of a quality that will withstand serious attempts against it. [1] and also happens to be the real owner of the lusercop.net domain name, no, he's not me, as you well know Now, admittedly, this does come down in a big way to the experience level of the ``programmer'' (and I use that word carefully) who writes the PHP, as often they are not aware of the way in which failures can be exploited and not really that interested in the consequences (which may end up backfiring on you as a server administrator). An example of this might be a script that used the mail function in such a way as to be an http-based open relay. This will rapidly get you blacklisted if noticed and exploited, and many people say well, they'll never notice me, why will they pick on me?. Due to the apparent difficulty in appropriately quoting for HTML, a lot of people don't realise that this is necessary, and end up with Cross- Site Scripting, which while not a real vulnerability is potentially nasty if combined with a cookie-based authentication system. I can see that it depends how much you care, and who is supporting the PHP application. My system allows users to run their own CGI's, though I think that those who will take advantage of this feature are either a) clueful enough to write them sensibly or b) able to ask me to check for possible holes. It is then their account which is at stake. PHP has access to all the other PHP applications in a normal setup (in much the same way as, say, mod_perl) and has the same security issues. If it matters to you that a user can write to files that your system-supported PHP application is attempting to maintain, then this would be bad. In my system, I would consider that to be undesirable. I think my conclusion for all of this is that I can't trust PHP, because architecturally, it appears to be designed for use in situations where the necessity is not for any kind of privilege management, or separation. It appears to be designed to get dynamic pages up and running as quickly as possible and as easily as possible. This tends to attract the people who don't understand the implications of the way they write their code, as a result of the ease of use. It's very easy to positively test something, much harder to negatively test it. -- Lusercop.net - LARTing Lusers everywhere since 2002
Re: webmail
[ Curse you `Lusercop', you know I can't resist a PHP-rant... ] On Tue, 29 Oct 2002, Lusercop wrote: On Tue, Oct 29, 2002 at 03:35:22PM +, Paul Makepeace wrote: I'd read this as FUD, frankly, until you can show PHP has suffered vulnerabilities so severe as to require shutting down service every few weeks. This might seem anal of me but people might actually take what you're saying to heart and then continue to spread disinformation. If a package deserves commentary like that (say MS not fixing reported bugs for after several weeks of being notified), fair enough, if it doesn't, it's worth IMO avoiding hyperbole. I read what you're saying, and I'm unlikely to support PHP on my server for similar reasons to Roger. Chris Andrews, who reads this list[1], can probably explain better, as he has to deal with user support for PHP. In essence, however, it seems to be very easy to write PHP in a way that it silently eats errors, fails to quote appropriately, and other such things, and much harder to write PHP of a quality that will withstand serious attempts against it. Of course, it's very easy to write such code in any language, but PHP's way of dealing with this is wrong. Instead of attempting to educate the user community as to how to write secure code, the PHP approach is to offer 'magic bullets', such as escapeshellcmd(), and to simply say 'you should use this, it makes everything better'. There are also a significant amount of convenience features, designed to reduce the overhead of getting a script up and running, such as injecting CGI variables as globals - yuck! Sure, this lets you embed little snippets of code into a web page very easily, but these days it looks to me like an indication of PHP's roots as SSI-on-steroids. You can take steps to lock PHP down, even on a shared server, but it's not the default state after install and there doesn't seem to be a canonical way of securing a shared PHP installation. Most importantly, if you *do* succeed in locking it down, your users will just complain that their scripts don't work. Worse, they will work around the 'security': just look in the user submitted notes for the 'Safe Mode' feature in the PHP manual for ways of avoiding it. Apart from anything else, the reason I don't use PHP on my personal machines is that I think it's about as good a language as a collision between all the bad bits of Perl and all of Visual Basic. Chris.
Re: webmail
On 29 Oct 2002 06:30:49, [EMAIL PROTECTED] (Randal L. Schwartz) said: However, I hate typing it. I hate having to type /foo when I get to the ending level. I want to just type a right-paren, watch my editor flash the corresponding left paren, and be done with it. This came up in my tech talk on presentation software, and is why I'm still using MagicPoint rather than writing AxPoint XML presentations by hand. Hitting tab is a lot more pleasing than typing point level=2. Of course, you can apply a filter and turn your POD into AxPoint's XML, blah, but it seems that you're ostensibly expected to talk XML to computers. Which is their job, not ours. :-) cue presentation software arguments all over again - Chris. -- $a=printf.net; Chris Ball | chris@void.$a | www.$a | finger: chris@$a Today is the car of the cdr of your life.
