Re: R. Berjon's Mod_perl site (was Re: Coldfusion vs. apache/mod_perl)
On Fri, 7 Jul 2000, Robin Berjon wrote: No need to apologize, we've all got a lot to do. Is it just a matter of committing the cvs or is there more to be done ? I have a little bit of time between now and the middle of the month, I can help if need be. jim took a snapshot of a subset of the site and applied his changes to it. i need to incorporate changes that have been made since the snapshot, and apply the template to the rest of the site. it'll be a fair amount of work, but perhaps i can do it in chunks, and i'll certainly commit the template, so perhaps folks can help with that part.
Re: Coldfusion vs. apache/mod_perl
On Wed, 5 Jul 2000, Bas wrote: Hi all, this is probably gonna be a longish one. It's about coldfusion vs. the combination of apache/mod_perl, I'm hoping to find some people on the list who have some experience with both, and who maybe faced a similar question. I've been searching the Net for a few days now to find opinions, but espec. in comparison to the apache/mod_perl combo, I couldn't find that much. Some intro: I work for a content syndication company; basically, we receive tons of different newsfeeds, we classify the content, both manually as well as automatically (based on fulltext and metadata queries), we add some extra content if it's not in the incoming data (for instance, we create a smaller version of a news story so it reads better on a WAP device), then we have quite a bit of distribution options: we do HTML, plain text, XML, using transports such as FTP, e-mail, HTTP Post, as well as host the news which customers can include dynamically in their website. You sound like you need to check out AxKit - it would probably fit your needs perfectly. Your templating needs are delivered using XSLT or XPathScript or XMLNews::HTMLTemplate, caching is taken care of, as is dynamic content (using XSP) and database queries (using the XSP SQL taglib). Take a look - hopefully you'll be impressed ;-) http://axkit.org/ BTW: I'll be giving a 2 hour talk on AxKit at ApacheCon Europe in October. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Coldfusion vs. apache/mod_perl
On Wed, 5 Jul 2000, Paul Lindner wrote: I've been toying with using the Apache::ASP custom tag feature to support cold-fusion like applications. I don't think it will be too hard; reading the spec it appears you need to make a list of named queries and then use cfoutput tags with #fieldname# entries. Not to dismiss Joshua's interesting looking extensions to Apache::ASP, but have you checked out AxKit's SQL taglib stuff? Here's an XSP to extract rows from a messages table: xsp:page language="Perl" xmlns:sql="http://www.apache.org/1999/SQL" xmlns:xsp="http://www.apache.org/1999/XSP/Core" page title="SQL Search Results" sql:execute-query sql:driverSybase/sql:driver sql:usernamewebboard/sql:username sql:passwordpassword/sql:password sql:doc-elementoptions/sql:doc-element sql:row-elementoption/sql:row-element sql:tag-caselower/sql:tag-case sql:null-indicatoryes/sql:null-indicator sql:id-attributeID/sql:id-attribute sql:id-attribute-columnmsgid/sql:id-attribute-column sql:queryselect * from Messages/sql:query sql:count-attributecount/sql:count-attribute /sql:execute-query /page /xsp:page This is then styled using XSLT in the next part of the pipeline. My box can deliver 14 hits/sec on this (executed and styled using XSLT on every hit). Not exactly blazing, but fast enough for a lot of uses. And don't be put off by the verbosity - all this can be modularised in external entities and/or taglibs. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Coldfusion vs. apache/mod_perl
On Thu, 6 Jul 2000, Gunther Birznieks wrote: Take a look - hopefully you'll be impressed ;-) http://axkit.org/ BTW: I'll be giving a 2 hour talk on AxKit at ApacheCon Europe in October. Holy s..t! this is a well-laid out site!! Could you do the same for perl.apache.org? :) BTW, if you are distributing as integration with GPL software, you don't have to make your stuff GPL too? Or is that Sablotron actually using the lesser/library version of GPL? Sablotron is MPL/GPL - same as Expat. But I'm confused over how this whole thing works with AxKit - I mean all I'm doing is providing a module that can work with Sablotron. You don't _have_ to use it. So I don't really see how this can affect my work, but this is one of the really confusing areas of the GPL, and it really needs an FAQ. (all of this of course has no relevance now that Sablotron can be distributed under the MPL). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Coldfusion vs. apache/mod_perl
On Thu, 6 Jul 2000, Gunther Birznieks wrote: Take a look - hopefully you'll be impressed ;-) http://axkit.org/ BTW: I'll be giving a 2 hour talk on AxKit at ApacheCon Europe in October. Holy s..t! this is a well-laid out site!! Could you do the same for perl.apache.org? :) Well of course AxKit gives me the consistent layout, and Robin Berjon gave me the design. He also did a perl.apache.org one, but people didn't like it - said it was too graphicy or something. Thats at http://www.knowscape.org/modperl/ It would be cool if perl.apache.org were to run AxKit ;-) BTW: My box-out is done using RSS, and is automatically updated. Thought people might like to know. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
R. Berjon's Mod_perl site (was Re: Coldfusion vs. apache/mod_perl)
Matt Sergeant wrote: Well of course AxKit gives me the consistent layout, and Robin Berjon gave me the design. He also did a perl.apache.org one, but people didn't like it - said it was too graphicy or something. Thats at http://www.knowscape.org/modperl/ Is too bad, I think this one looks really _slick_. It'd get my vote. -- Graham TerMarsch // - // Ignorance is when you don't know anything and somebody finds it out. // -
Re: R. Berjon's Mod_perl site (was Re: Coldfusion vs. apache/mod_perl)
At 09:15 07/07/2000 +0800, Gunther Birznieks wrote: At 08:36 AM 7/6/00 -0700, Graham TerMarsch wrote: Matt Sergeant wrote: Well of course AxKit gives me the consistent layout, and Robin Berjon gave me the design. He also did a perl.apache.org one, but people didn't like it - said it was too graphicy or something. Thats at http://www.knowscape.org/modperl/ Is too bad, I think this one looks really _slick_. It'd get my vote. Even if some don't think it's perfect, it's certainly better than the one now I would think? I don't know where things are at re the refacing of the perl.apache.org website. Part of it not happening before has been my fault for being caught up to the neck in work and not taking care of it. I think the new site was about to be committed but I don't know what happened with that. One recent suggestion likely to make people happier in the graphicy vs developery thing would be to have developer.modperl.org for developers and www.modperl.org for advocacy. I'm ready to do some work on this this summer if there is stuff to be done. PS: Discussion of such things would be better suited for [EMAIL PROTECTED] I guess. -- robin b. Immature poets imitate, mature poets steal. -- T.S. Eliot
Re: R. Berjon's Mod_perl site (was Re: Coldfusion vs. apache/mod_perl)
At 21:12 06/07/2000 -0700, brian moseley wrote: On Thu, 6 Jul 2000, Robin Berjon wrote: I think the new site was about to be committed but I don't know what happened with that. One recent my apologies. i've been meaning to do it, but real life has gotten in the way. i'll have it done by the end of the weekend. No need to apologize, we've all got a lot to do. Is it just a matter of committing the cvs or is there more to be done ? I have a little bit of time between now and the middle of the month, I can help if need be. suggestion likely to make people happier in the graphicy vs developery thing would be to have developer.modperl.org for developers and www.modperl.org for advocacy. I'm ready to do some work on this this summer if there is stuff to be done. i really like this idea. a lot. Me too, the only hindrance I see is that it would probably take writing some of the advocacy stuff, which could take time. i suppose, but i still like to hear people's opinions, and nobody really ever discusses anything on advocacy. I don't really care, it's just in case people don't want to hear about this :) -- robin b. All paid jobs absorb and degrade the mind. -- Aristotle
Coldfusion vs. apache/mod_perl
Hi all, this is probably gonna be a longish one. It's about coldfusion vs. the combination of apache/mod_perl, I'm hoping to find some people on the list who have some experience with both, and who maybe faced a similar question. I've been searching the Net for a few days now to find opinions, but espec. in comparison to the apache/mod_perl combo, I couldn't find that much. Some intro: I work for a content syndication company; basically, we receive tons of different newsfeeds, we classify the content, both manually as well as automatically (based on fulltext and metadata queries), we add some extra content if it's not in the incoming data (for instance, we create a smaller version of a news story so it reads better on a WAP device), then we have quite a bit of distribution options: we do HTML, plain text, XML, using transports such as FTP, e-mail, HTTP Post, as well as host the news which customers can include dynamically in their website. The parts that involve website development are currently done exclusively using apache and mod_perl, this makes up about 35% of our overall system. Now, it seems that Allaire's product, Spectra, does offer us a solution to (parts of) our problems. I'm not sure yet exactly what problem it solves, we still have to establish that, but let's assume it does. Spectra is a product built using Allaire's ColdFusion. That means that if we have to add functionality to Spectra, we'll be using coldfusion to develop that. To assess coldfusion, I installed the eval version on one of our Linux boxes to explore it. Here are some of my observations: 1- "Code inside HTML" coldfusion's like PHP or ASP in that you embed most of your code inside HTML pages. I don't like it; I prefer to use some templating system that allows our HTML wizards to edit HTML, and our perl wizards to code perl. But let's not start that discussion: we've seen it before ;) 2- Feature comparison If I compary the features available in the coldfusion appserver with the available options for mod_perl, I don't see a lot of extra's: - session management We do that using our own Web::Session implementation (very much like Apache::Session). It can do that either using cookies or stick the session id in the URL. coldfusion seems to require cookies. - database connection pooling We use Apache::DBI; - Scheduled tasks We use cron; - Sending mail from within the appserver Tons of CPAN modules can do this. Great MIME stuff there too; - Retrieve web page and stick into local file This is a built-in feature of the appserver. lwp-mirror can do this just fine. - coldfusion can use COM (or is that ActiveX?) Apparently, there are a lot of those thingies to stick into coldfusion and use that from within your code. We run HP-UX; those won't work for us. - coldfusion can be clustered (apparently automagically) So far I haven't had the need to do this; our HP box with 4 processors never gets a load above 0.2. I assume with Apache running on a few boxes, some load-balancing hardware in front of those, and some URL rewriting and/or smarter session management, clustering could be accomplished as well. I doubt we need this though. If we do high volume content serving, I'll convert the dynamic content to static html or xml, ftp them over to a box running a non-mod_perl Apache and serve 'm from there. I never measured this too well, I think it did something like 400 reqs/second on Intel hardware running Linux. 3- Complexity of layers (or would those be called 'tiers'?) With mod_perl, I have to make sure Apache runs (Ok; I need to get the stuff compiled too. I can do that. By now ;)), so far, I haven't seen Apache go down ever. With coldfusion, aside from Apache, I have to make sure a bunchful of different coldfusion apps are running. How stable are those apps? Also, I don't know how coldfusion talks to Oracle. DBI/DBD::Oracle works good enough. 4- Developer community Concluding from the amount of hits I got searching dejanews etc., the coldfusion developer community is hiding out somewhere else. On Allaire's site, success stories sound great; mod_perl's success stories on perl.apache.org do too, but they don't contain a lot of buzzwords (;) ). I'd love to hear some opinions on this. I'm not looking for "stick to what you know"-kinda replies; I know that already. It's just that *if* Spectra does provide needed functionality, it will be faster to buy it than it is to develop the same functionality using apache/mod_perl. Yet, I do want to know what I'll be getting into when I need to work with coldfusion on a daily basis vs. working with apache/mod_perl on a daily basis. Regards, bas.
RE: Coldfusion vs. apache/mod_perl
I just left a company that used either mod_perl or coldfusion for our intranet development. I never did any coldfusion development but I did have to deal with maintaing the coldfusion server and apps. coldfusion crashed several times in the three or four months I was involved with it. We never could determine what the problem was. coldfusion (like Apache/mod_perl) eats memory. Our coldfusion processes usually used a total of 200MB of memory. coldfusion does not play well on unix (at least solaris). Allaire's site recommended changing some kernel parameters to get the best performance out of cold fusion. That was something we weren't willing to do on a box that had much more than CF running on it. To my knowledge, CF does not give you the power to mess with the web servers API like mod_perl does. You may or may not need this ability. IMHO, mod_perl applications easily out-performed our CF apps. One plus for coldfusion, there seems to be more CF developers out there (at least in Austin, TX) but that may be a sign that very few people are using CF. My opinion: stick to mod_perl, it won't let you down. On 05-Jul-2000 Bas wrote: Hi all, this is probably gonna be a longish one. It's about coldfusion vs. the combination of apache/mod_perl, I'm hoping to find some people on the list who have some experience with both, and who maybe faced a similar question. I've been searching the Net for a few days now to find opinions, but espec. in comparison to the apache/mod_perl combo, I couldn't find that much. Some intro: I work for a content syndication company; basically, we receive tons of different newsfeeds, we classify the content, both manually as well as automatically (based on fulltext and metadata queries), we add some extra content if it's not in the incoming data (for instance, we create a smaller version of a news story so it reads better on a WAP device), then we have quite a bit of distribution options: we do HTML, plain text, XML, using transports such as FTP, e-mail, HTTP Post, as well as host the news which customers can include dynamically in their website. The parts that involve website development are currently done exclusively using apache and mod_perl, this makes up about 35% of our overall system. Now, it seems that Allaire's product, Spectra, does offer us a solution to (parts of) our problems. I'm not sure yet exactly what problem it solves, we still have to establish that, but let's assume it does. Spectra is a product built using Allaire's ColdFusion. That means that if we have to add functionality to Spectra, we'll be using coldfusion to develop that. To assess coldfusion, I installed the eval version on one of our Linux boxes to explore it. Here are some of my observations: 1- "Code inside HTML" coldfusion's like PHP or ASP in that you embed most of your code inside HTML pages. I don't like it; I prefer to use some templating system that allows our HTML wizards to edit HTML, and our perl wizards to code perl. But let's not start that discussion: we've seen it before ;) 2- Feature comparison If I compary the features available in the coldfusion appserver with the available options for mod_perl, I don't see a lot of extra's: - session management We do that using our own Web::Session implementation (very much like Apache::Session). It can do that either using cookies or stick the session id in the URL. coldfusion seems to require cookies. - database connection pooling We use Apache::DBI; - Scheduled tasks We use cron; - Sending mail from within the appserver Tons of CPAN modules can do this. Great MIME stuff there too; - Retrieve web page and stick into local file This is a built-in feature of the appserver. lwp-mirror can do this just fine. - coldfusion can use COM (or is that ActiveX?) Apparently, there are a lot of those thingies to stick into coldfusion and use that from within your code. We run HP-UX; those won't work for us. - coldfusion can be clustered (apparently automagically) So far I haven't had the need to do this; our HP box with 4 processors never gets a load above 0.2. I assume with Apache running on a few boxes, some load-balancing hardware in front of those, and some URL rewriting and/or smarter session management, clustering could be accomplished as well. I doubt we need this though. If we do high volume content serving, I'll convert the dynamic content to static html or xml, ftp them over to a box running a non-mod_perl Apache and serve 'm from there. I never measured this too well, I think it did something like 400 reqs/second on Intel hardware running Linux. 3- Complexity of layers (or would those be called 'tiers'?) With mod_perl, I have to make sure Apache runs (Ok; I need to get the stuff compiled too. I can do that. By now ;)), so far, I haven't seen Apache go down ever. With coldfusion, aside from Apache, I have to make
Re: Coldfusion vs. apache/mod_perl
On Wed, Jul 05, 2000 at 04:30:01PM -0500, [EMAIL PROTECTED] wrote: I just left a company that used either mod_perl or coldfusion for our intranet development. I never did any coldfusion development but I did have to deal with maintaing the coldfusion server and apps. coldfusion crashed several times in the three or four months I was involved with it. We never could determine what the problem was. coldfusion (like Apache/mod_perl) eats memory. Our coldfusion processes usually used a total of 200MB of memory. coldfusion does not play well on unix (at least solaris). Allaire's site recommended changing some kernel parameters to get the best performance out of cold fusion. That was something we weren't willing to do on a box that had much more than CF running on it. To my knowledge, CF does not give you the power to mess with the web servers API like mod_perl does. You may or may not need this ability. IMHO, mod_perl applications easily out-performed our CF apps. One plus for coldfusion, there seems to be more CF developers out there (at least in Austin, TX) but that may be a sign that very few people are using CF. My opinion: stick to mod_perl, it won't let you down. I've been toying with using the Apache::ASP custom tag feature to support cold-fusion like applications. I don't think it will be too hard; reading the spec it appears you need to make a list of named queries and then use cfoutput tags with #fieldname# entries. This is absurdly simple with Joshua's new Apache::ASP. Just define cfoutput as a custom tag, and write a small handler for it. I'll have to look up the other tags they support, but they shouldn't be too hard to implement... Has anyone else out there wrote their own cold-fusion routines? -- Paul Lindner [EMAIL PROTECTED] Red Hat Inc.
Re: Coldfusion vs. apache/mod_perl
On Wed, Jul 05, 2000 at 04:09:06PM -0700, Joshua Chamas wrote:
Paul Lindner wrote:
IMHO, mod_perl applications easily out-performed our CF apps.
One plus for coldfusion, there seems to be more CF developers out there (at
least in Austin, TX) but that may be a sign that very few people are using CF.
My opinion: stick to mod_perl, it won't let you down.
I've been toying with using the Apache::ASP custom tag feature to
support cold-fusion like applications. I don't think it will be too
hard; reading the spec it appears you need to make a list of named
queries and then use cfoutput tags with #fieldname# entries.
This is absurdly simple with Joshua's new Apache::ASP. Just define
cfoutput as a custom tag, and write a small handler for it.
I'll have to look up the other tags they support, but they shouldn't
be too hard to implement...
Has anyone else out there wrote their own cold-fusion routines?
Hey Paul,
I think you will have a problem with cold fusion templating
logic like if/else constructs. For these, I would recommend
having something like a ColdFusionCompat config setting, and we
could rip out some of these are parse time and convert them into the
ASP style constructs.
One idea is to have a separate class of tags that are used in the
parse stage.:
CodeTags (cfif|cfelse|cfend)
sub cfend {
return('}');
}
sub cfelse {
return('} else {');
}
sub cfif {
. # heavy lifting here..
return('if (..) {');
}
I am planning to use this approach for support of XSP logic
for XML/XSLT integration, and can't see how to use the custom
tags for full logic implementations of other environments,
particularly the if/else contructs. Might there be some
way to extend the XMLSubsMatch technology to coordinate
between multiple tags?
I think what we need to is something like a Script_OnParse
that one could use to grab the script data and parse it
before the ASP to perl compiler gets to it. This would
allow for some experimentation out of the code base before
merging in something big like XSP or ColdFusion support.
That would definitely do the trick too. Though instead I'd use
various regular expressions to convert tags into ASP syntax..
--
Paul Lindner
[EMAIL PROTECTED]
Red Hat Inc.
Re: Coldfusion vs. apache/mod_perl
Anyone looked at PHP???
Paul Lindner wrote:
On Wed, Jul 05, 2000 at 04:09:06PM -0700, Joshua Chamas wrote:
Paul Lindner wrote:
IMHO, mod_perl applications easily out-performed our CF apps.
One plus for coldfusion, there seems to be more CF developers out there (at
least in Austin, TX) but that may be a sign that very few people are using CF.
My opinion: stick to mod_perl, it won't let you down.
I've been toying with using the Apache::ASP custom tag feature to
support cold-fusion like applications. I don't think it will be too
hard; reading the spec it appears you need to make a list of named
queries and then use cfoutput tags with #fieldname# entries.
This is absurdly simple with Joshua's new Apache::ASP. Just define
cfoutput as a custom tag, and write a small handler for it.
I'll have to look up the other tags they support, but they shouldn't
be too hard to implement...
Has anyone else out there wrote their own cold-fusion routines?
Hey Paul,
I think you will have a problem with cold fusion templating
logic like if/else constructs. For these, I would recommend
having something like a ColdFusionCompat config setting, and we
could rip out some of these are parse time and convert them into the
ASP style constructs.
One idea is to have a separate class of tags that are used in the
parse stage.:
CodeTags (cfif|cfelse|cfend)
sub cfend {
return('}');
}
sub cfelse {
return('} else {');
}
sub cfif {
. # heavy lifting here..
return('if (..) {');
}
I am planning to use this approach for support of XSP logic
for XML/XSLT integration, and can't see how to use the custom
tags for full logic implementations of other environments,
particularly the if/else contructs. Might there be some
way to extend the XMLSubsMatch technology to coordinate
between multiple tags?
I think what we need to is something like a Script_OnParse
that one could use to grab the script data and parse it
before the ASP to perl compiler gets to it. This would
allow for some experimentation out of the code base before
merging in something big like XSP or ColdFusion support.
That would definitely do the trick too. Though instead I'd use
various regular expressions to convert tags into ASP syntax..
--
Paul Lindner
[EMAIL PROTECTED]
Red Hat Inc.
--
Chris Fry
Quillsoft Pty Ltd
10 Gray Street
Kogarah
NSW 2217
Australia
Phone: +61 2 9553 1691
Fax: +61 2 9553 1692
Mobile: 0419 414 323
eMail: [EMAIL PROTECTED]
http://www.quillsoft.com.au
Re: Coldfusion vs. apache/mod_perl
Paul Lindner wrote:
Hey Paul,
I think you will have a problem with cold fusion templating
logic like if/else constructs. For these, I would recommend
having something like a ColdFusionCompat config setting, and we
could rip out some of these are parse time and convert them into the
ASP style constructs.
One idea is to have a separate class of tags that are used in the
parse stage.:
CodeTags (cfif|cfelse|cfend)
sub cfend {
return('}');
}
sub cfelse {
return('} else {');
}
It would be nice to have this extension, I can see why,
so instead of executing the XMLSubs at runtime, they
would be executed at compile time, which would prevent
them from being defined in the script itself being
compiled. Have to be in global.asa or some perllib.
Note that in global.asa, there could be the likes of
*cfend = *CF::Tags::end;
*cfelse = *CF::Tags::else;
So, how would a XMLParseSubsMatch config be for this
behavior?
-- Joshua
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
