perl-asp mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Chamas <>
Subject Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
Date Thu, 22 May 2014 17:01:11 GMT
On 5/21/14 11:45 PM, Tsirkin Evgeny wrote:
> It has been a while.
> Josh it is great you a here .

Thanks, its good to be back!

> After Warren took the time to compare Dancer to Apache::ASP i had to look into
> the framework.
> Just read the Cookbook .
> It seems like the Dancer is following the famous MVC/Ruby on Rails where it can.
> Routing,Layouts,DSL (OK ,Ruby is a DSL in a way by itself).
> Apache::ASP is more like php in old days ,put a page and it will work.

KISS!  I love things that just work too!

> I still think that Apache::ASP has it's place.Not just for legacy.
> Putting a .asp file and have it work is an advantage.
> It is a good idea to have a module/method be called with routing.
> I know I miss it a lot for AJAX and data processing requests.

You know I have not much followed the routing paradigms.  To me it seems that 
this would be an area I would have solved with a mod_rewrite or a mod_perl 
handler, changing up the URL destination on the back end.  But that is old 
school me.  I wonder if Apache::ASP were to be made to work with something like 
Plack, if it would pick up some routing potential on the way (or maybe just a 
Plack way of doing things?)

> The most problem with Apache::ASP for by now is that it is tied to mod_perl
> with it's module reloading ,memory hogging problems.

Yes, always been a problem, but memory is so cheap! :)

It used to be that throwing up a mod_proxy in front of mod_perl was the best way 
to limit the memory issues (as well as some preload of Apache::ASP in the parent 
httpd process), but these days it seems that having an nginx in from of a 
mod_perl apache would be better, and limit the # of processes there.

> So I will be glad to invest some time in helping porting Apache::ASP and
> introduce whatever is missing ,at least for me.
> Evgeny



> On Thu, May 22, 2014 at 2:52 AM, Josh Chamas <
> <>> wrote:
>     Thanks Warren for the write up!  Sounds pretty exciting going full on into a
>     new framework and having that stick even better.
>     I built Apache::ASP back in the day when both PHP and Java were toys (even
>     Linux was half baked), and glue of the web and unix systems was often perl,
>     my first love of a language.  Its all gotten a bit more evolved since then
>     to say the least. :)
>     & thanks for hanging out these past years on the list!
>     Cheers,
>     Josh
>     On 5/21/14 4:42 PM, Warren Young wrote:
>         On 5/20/2014 13:06, Josh Chamas wrote:
>             So where does this put you in the consideration of platform migration
>             etc? Plack, Mason, TT, etc.
>         Shortly after I started this thread, I decided to just try one of the
>         alternatives, for education value if nothing else.
>         I narrowed my options to Dancer and Mason+Poet, as those are the only two
>         popular, full-featured, actively-developed Perl web frameworks that
>         still run
>         under Perl 5.8, which we're going to have to support for years yet.
>           Mojolicious
>         and Catalyst are the other main options, and they both require 5.10.
>         Mason is functionally quite similar to Apache::ASP, whereas I'd say less
>         than
>         50% of Dancer directly maps to the ASP way of doing things. Nevertheless, I
>         decided to start with Dancer purely because it has a more active mailing
>         list.
>         I told myself that I would fall back to Mason if the Dancer experiment
>         fizzled.
>         As it turned out, Dancer delivered in spades, so I never did spend any
>         time with
>         Mason+Poet.
>         About the only things in Dancer that map 1:1 to Apache::ASP -- or near
>         enough
>         that simple regexes can fix up most of the differences -- are the Request,
>         Response and Session objects.
>         Dancer differs from Apache::ASP in pretty much every other way:
>         - There is no direct equivalent of Apache::ASP's Application and Server
>         objects.  The features are all present in Dancer, but not collected
>         together in
>         the same way.  For example, $Server->Config('foo') is config->{foo} in
>         Dancer.
>         (As a rule, Dancer function and object names are shorter than in
>         Apache::ASP.
>         For another example, $Request->QueryString('foo') is param 'foo' in Dancer.)
>         - Dancer's API is a DSL rather than idiomatic Perl as in Apache::ASP. This
>         bothers to about the same extent that <script> blocks in an HTML file bother
>         me.  Bouncing between languages adds a context switch while reading
>         code; it's
>         worst when you have blocks of code that fill a screen, so that you have to
>         remember context of language A across a screenful of language B.
>         Apache::ASP can't throw stones, though, due to the mixing of Perl and
>         HTML in
>         *.asp files.  It's easier to wrap the Dancer DSL in a Perlish API than
>         it is to
>         avoid Perl code in *.asp files.
>         - Apache::ASP's URL handing is file-based.  That is, the mere existence of
>         $webroot/foo.asp means http://server/foo.asp is a legal URL.  Dancer,
>         like many
>         newer frameworks, has a route-based URL system, meaning that you define your
>         dynamic URL hierarchy in code, rather than in the filesystem.  (Static
>         resource
>         files are still mapped directly to URLs in Dancer, of course.)
>         The files your route handlers use to fulfill each request is entirely up
>         to the
>         you.  Some kind of straightforward 1:1 mapping (e.g. /foo/bar uses
>         views/foo/ <>) is sensible, but not by any means
>         required.
>         - Dancer encourages you to separate your GET and POST handlers into separate
>         routes, whereas with Apache::ASP, the path of least resistance is to put
>         them
>         both in the same file, for much the same reason that CGI scripts have
>         GET and
>         POST handling in the same file.  You end up with stuff like:
>               if ($Request->{Method} eq 'POST') {
>                   # Examine $Request->Form to figure out what kind of POST it is,
>                   # extract data from the form data, process it, etc.
>               }
>               else {
>                   # Do something entirely different for GET
>               }
>               # Render page, either a fresh one for the GET case, or a response to
>               # a form submission in the POST case.
>         Separating your POST and GET routes reduces at least one indent level,
>         and keeps
>         mostly-unrelated code separate.  It also works better with Ajax-based code,
>         since GET usually returns HTML, whereas POST will more likely return JSON.
>         - Dancer has built-in automatic data serializers for several common formats:
>         JSON, XML, YAML, Data::Dumper...
>         This is great for Ajax code since:
>               return {
>                   foo => 'some value',
>                   bar => ( 'a', 'set', 'of', 'other', 'values' ),
>               }
>         ...serializes naturally to a JSON object.  My Apache::ASP pages that
>         returned
>         JSON had to manually set Content-Type and manually call
>         JSON::encode_json() to
>         serialize my Perl objects for return from Ajax handlers.
>         - Dancer offers many different templating systems, whereas Apache::ASP
>         offers
>         just the one.  Only one of the templating systems with a Dancer adapter
>         on CPAN
>         -- Mason -- works anything like the ASP templating language, in that it
>         allows
>         you to freely intermix HTML and Perl.  I initially tried using Dancer +
>         Mason to
>         minimize the amount of work needed to translate my ASP code, but after
>         running
>         into some difficulties I switched to Text::Xslate, and got hooked.
>         Systems like Xslate force you to collect all of the Perl code to build a
>         page
>         into one location, and write the template as a separate file.  This
>         makes both
>         the Perl and template code clearer, since you're not visually jumping
>         back and
>         forth between languages, as touched on above.
>         Template systems like this get you a lot of the benefits of the MVC paradigm
>         without trying to hammer your square app into the round MVC hole.
>         (That's another reason I rejected Catalyst, by the way.  My app really
>         only has
>         Views.  The closest thing to a Controller is the back-end server, written in
>         C++.  There's a Model, but the Perl code doesn't talk directly to it
>         through a
>         framework-mandated DBI/ORM scheme; in my app, the Model is hidden behind an
>         application server.  MVC web frameworks assume M, V, and C are all in
>         Perl, or
>         at most one hop away such as a MySQL DB via DBI.  Both Apache::ASP and
>         Dancer
>         (and Mason for that matter) are policy-free frameworks, not prescribing
>         specific
>         ways of building your app.)
>         I tell you all this because what happened is that after climbing the initial
>         learning cliff, I didn't run into any serious trouble.  Dancer just kept
>         delivering.  Every time I tried porting over another tricky part of the
>         web app,
>         it was just as easy to get it working with Dancer as with Apache::ASP,
>         and often
>         the result was easier to understand.
>         I don't say this to disparage Apache::ASP.  It's a fine framework, and
>         did the
>         job for us for a dozen years.  For that, Josh, I thank you.
>         The thing about Dancer is that it's simply based on a more modern, more
>         mature
>         design.  Separation of concerns, multi-level logging, web stack independence
>         thru PSGI/Plack, etc.
>         Because I kept failing to run into a wall with Dancer, and because the
>         future of
>         mod_perl looks so uncertain -- certainly on RHEL out of the box -- I
>         just kept
>         translating more and more pieces of my app.  It's now running
>         flawlessly.  The
>         code is far clearer, partly because of the mature Dancer design, but also
>         because the forced refactoring made me look at code I hadn't touched in
>         years
>         and bring it up to date.
>         Our new version is also faster, in large part because for our app, a single
>         long-lived application process has no downsides worth mentioning.  We
>         don't need
>         parallel dynamic code generation, since our app rarely has even 100
>         simultaneous
>         users per site, and those are mostly idle all the time.  Thus, the only
>         thing
>         that really needs to be parallelized is the static content, which is readily
>         done with Apache + mod_proxy or nginx.
>         Because of that, we can use fast in-memory sessions, we don't need a
>         bunch of
>         heavy Apache children hanging around and getting re-created every 500
>         conns, our
>         back end app server connections can stay up as long as the session stays
>         up, etc.
>         I therefore say with fondness and a tinge of regret, "So long, and
>         thanks for
>         all the fish."
>         I will remain subscribed, since this is a low-volume list.  I may be able to
>         continue helping others with Apache::ASP.  For myself, though, I'm a
>         convert.
>         All new code will be in Dancer.
>         ------------------------------__------------------------------__---------
>         To unsubscribe, e-mail: asp-unsubscribe@perl.apache.__org
>         <>
>         For additional commands, e-mail:
>         <>
>     ------------------------------__------------------------------__---------
>     To unsubscribe, e-mail: asp-unsubscribe@perl.apache.__org
>     <>
>     For additional commands, e-mail:
>     <>

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message