Mailing List Archive

Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
mod_perl no longer builds against Apache 2.4[1]. Consequently, the RHEL
7 beta doesn't include it[2].

The claimed replacement is mod_fcgid, but as far as I can tell from the
Apache::ASP CGI page[3] the standalone CGI mode seems to require plain
Perl scripts, not intermixed HTML + ASP/Perl files.

So, does this effectively kill Apache::ASP? Is there another path
forward, or should I be looking to migrate to some other framework?
(Catalyst?)



[1] http://www.apachelounge.com/viewtopic.php?p=25033
[2] http://goo.gl/Vn2Sxy
[3] http://apache-asp.org/cgi.html

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid? [ In reply to ]
Hi Warren!

I am happy to look at helping get Apache::ASP to work under a new environment
but it does seem that there is some progress on getting mod_perl to work under
Apache 2.4. It sounds like some distros actually have this working and possibly
built on the "httpd24 development branch of mod_perl"

http://www.gossamer-threads.com/lists/modperl/modperl/105641

The ETAs seems pretty weak on when you should expect this to be working. Might
be worth looking at that development branch and see what's possible there or
what patches other distros are using?

Regards,

Josh


On 12/27/13 3:30 PM, Warren Young wrote:
> mod_perl no longer builds against Apache 2.4[1]. Consequently, the RHEL 7 beta
> doesn't include it[2].
>
> The claimed replacement is mod_fcgid, but as far as I can tell from the
> Apache::ASP CGI page[3] the standalone CGI mode seems to require plain Perl
> scripts, not intermixed HTML + ASP/Perl files.
>
> So, does this effectively kill Apache::ASP? Is there another path forward, or
> should I be looking to migrate to some other framework? (Catalyst?)
>
>
>
> [1] http://www.apachelounge.com/viewtopic.php?p=25033
> [2] http://goo.gl/Vn2Sxy
> [3] http://apache-asp.org/cgi.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
> For additional commands, e-mail: asp-help@perl.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid? [ In reply to ]
On 12/27/2013 17:04, Josh Chamas wrote:
>
> it does seem that there is some progress on getting
> mod_perl to work under Apache 2.4.

I was aware of such efforts when I posted, but didn't mention the option
since this third-party mod_perl work feels like a temporary solution.
We don't want to use a hack to get us through to RHEL 8, then be back in
the same stew pot.

Besides, we already have an effective option for limping by. RHEL 5 and
6 will still be useful to us for years, and RHEL 7 is probably a large
fraction of a year from release. This gives us enough time to move to a
system we won't have to replace again in another 3 years.

The question is, will that system be Apache::ASP 3? Apache::ASP::TNG?
Apache::ASP::TheSearchForSPDY?

What would it take to migrate the full ASP model to Plack + mod_fcgid?
(http://plackperl.org/) That seems to be the way the cool kids are
doing their Perl web frameworks these days. Is it just a matter of
replacing all the Apache::Foo module calls with Plack or PSGI
equivalents? I assume all the MLDBM stuff doesn't have to change.

From our point of view, Apache::ASP has two main pieces: the ASP object
model and the ASP/JSP/PHP style template system.

We could probably automate a conversion of our entire app from ASP style
templating to Mason, Mojo::Template or Template::Toolkit in a week,
tops. Tedious, but technically trivial.

The real thing keeping us on Apache::ASP -- besides inertia -- is the
ASP object model.

Most of the ASP object model has direct replacements in any reasonable
Perl web framework, such that conversion is about as trivial as
converting the templating code.

$Session is the only object that looks hard to convert from. We have
hundreds of references to that object in our app, and state management
is the sort of thing that gets done a zillion different ways. There
probably is no existing Perl web framework that does it quite the same
way as Apache::ASP.

We also have to consider backwards compatibility. If we move the app to
another framework, we effectively fork our code base, requiring parallel
development on any feature that has to be backported to prior versions.
(Or, we have to replace each existing site's Apache::ASP deployment
in-place to do a version upgrade.)

It might be worth taking the time it would take to convert to another
web framework and put it into an Apache::ASP 3 effort.

I'm feeling equivocal about that, though. There are faster frameworks,
and greater popularity confers direct tangible benefits.

Feh.

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid? [ In reply to ]
Hi Warren!

My apologies for the long delay, with some big & unexpected events slowing me
down earlier this year, I finally got a chance to look at getting Apache::ASP
running with mod_perl + Apache 2.4... it seems like work is being done in this
area and there may be a rough release coming soon with mod_perl 2.09 for real
Apache 2.4 support.

One thing I thought was interesting in researching Apache 2.4 vs. Apache 2.2 was
that it seems that the vast majority of the active install base is still on
Apache 2.2 towards 90%+ in Netcraft & W3Tech surveys, and many have complained
with general upgrade issues to 2.4. It seems then that 2.2 will have a lot of
support/momentum for some time, and your timeline of years seems about right...

So where does this put you in the consideration of platform migration etc?
Plack, Mason, TT, etc. I am not sure how hard it would be to migrate to Plack.
Their is basic support in the Apache::ASP core to handle running in different
environments including pure CGI and command line, the latter used for
bootstrapping the make test mode. Might take days to get something rough
working there. I agree mixing the Apache::ASP object model into another
template framework would make for more difficult work, and you might end up with
a mess besides! I am curious to hear how your platform decision plays out here!

Regards,

Josh

Netcraft survey suggesting 1-2% usage of Apache 2.4 as of Feb.

http://news.netcraft.com/archives/2014/02/07/are-there-really-lots-of-vulnerable-apache-web-servers.html

W3Tech survey showing 90% 2.2 usage as of May
http://w3techs.com/technologies/details/ws-apache/2/all

Here is the April mod_perl 2.09 status update (copied below)
http://mail-archives.apache.org/mod_mbox/perl-modperl/201404.mbox/browser


====
"The latest release of mod_perl doesn't yet support httpd-2.4, but we
are working on it and getting close to making a new release that does.

In the meantime you might like to try out the "httpd24threading" branch at

https://svn.apache.org/repos/asf/perl/modperl/branches/httpd24threading

which is largely working and is what will (hopefully soon) become mod_perl-2.09."
====


On 12/27/13 5:33 PM, Warren Young wrote:
> On 12/27/2013 17:04, Josh Chamas wrote:
>>
>> it does seem that there is some progress on getting
>> mod_perl to work under Apache 2.4.
>
> I was aware of such efforts when I posted, but didn't mention the option since
> this third-party mod_perl work feels like a temporary solution. We don't want to
> use a hack to get us through to RHEL 8, then be back in the same stew pot.
>
> Besides, we already have an effective option for limping by. RHEL 5 and 6 will
> still be useful to us for years, and RHEL 7 is probably a large fraction of a
> year from release. This gives us enough time to move to a system we won't have
> to replace again in another 3 years.
>
> The question is, will that system be Apache::ASP 3? Apache::ASP::TNG?
> Apache::ASP::TheSearchForSPDY?
>
> What would it take to migrate the full ASP model to Plack + mod_fcgid?
> (http://plackperl.org/) That seems to be the way the cool kids are doing their
> Perl web frameworks these days. Is it just a matter of replacing all the
> Apache::Foo module calls with Plack or PSGI equivalents? I assume all the MLDBM
> stuff doesn't have to change.
>
> From our point of view, Apache::ASP has two main pieces: the ASP object model
> and the ASP/JSP/PHP style template system.
>
> We could probably automate a conversion of our entire app from ASP style
> templating to Mason, Mojo::Template or Template::Toolkit in a week, tops.
> Tedious, but technically trivial.
>
> The real thing keeping us on Apache::ASP -- besides inertia -- is the ASP object
> model.
>
> Most of the ASP object model has direct replacements in any reasonable Perl web
> framework, such that conversion is about as trivial as converting the templating
> code.
>
> $Session is the only object that looks hard to convert from. We have hundreds
> of references to that object in our app, and state management is the sort of
> thing that gets done a zillion different ways. There probably is no existing
> Perl web framework that does it quite the same way as Apache::ASP.
>
> We also have to consider backwards compatibility. If we move the app to another
> framework, we effectively fork our code base, requiring parallel development on
> any feature that has to be backported to prior versions. (Or, we have to
> replace each existing site's Apache::ASP deployment in-place to do a version
> upgrade.)
>
> It might be worth taking the time it would take to convert to another web
> framework and put it into an Apache::ASP 3 effort.
>
> I'm feeling equivocal about that, though. There are faster frameworks, and
> greater popularity confers direct tangible benefits.
>
> Feh.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
> For additional commands, e-mail: asp-help@perl.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid? [ In reply to ]
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/bar.tt) 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: asp-help@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid? [ In reply to ]
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/bar.tt) 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: asp-help@perl.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid? [ In reply to ]
It has been a while.
Josh it is great you a here .

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.

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.

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.

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 <josh@chamas.com> 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/bar.tt) 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: asp-help@perl.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
> For additional commands, e-mail: asp-help@perl.apache.org
>
>
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid? [ In reply to ]
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

Thanks!

Josh

>
>
> On Thu, May 22, 2014 at 2:52 AM, Josh Chamas <josh@chamas.com
> <mailto:josh@chamas.com>> 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/bar.tt <http://bar.tt>) 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
> <mailto:asp-unsubscribe@perl.apache.org>
> For additional commands, e-mail: asp-help@perl.apache.org
> <mailto:asp-help@perl.apache.org>
>
>
> ------------------------------__------------------------------__---------
> To unsubscribe, e-mail: asp-unsubscribe@perl.apache.__org
> <mailto:asp-unsubscribe@perl.apache.org>
> For additional commands, e-mail: asp-help@perl.apache.org
> <mailto:asp-help@perl.apache.org>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid? [ In reply to ]
On 5/21/2014 17:52, Josh Chamas wrote:
>
> 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.

One of my requirements was in fact that the next framework be
Perl-based, and only partly because we had all this code already
written. The other reason, of course, is that Perl remains a highly
productive language for me. I still reach for it first when writing
anything "scripty," despite knowing a dozen or so other languages that
could also accomplish the task.

As Bjarne said[1], there are the languages everyone complains about, and
the ones nobody uses. :)


[1] http://www.stroustrup.com/bs_faq.html#really-say-that

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid? [ In reply to ]
On 5/22/2014 00:45, Tsirkin Evgeny wrote:
>
> It seems like the Dancer is following the famous MVC/Ruby on Rails where
> it can.

Dancer is actually a Perl reimplementation of a Ruby framework called
Sinatra. (Get it? Dancer? Sinatra? Ahahaha.)

Dancer is very much *not* MVC, only V.

The problem with MVC systems is that they only work when you can write
your M's and C's in the same framework, or connect directly to them.
They also presume that there are M's and C's to be had in the first
place. I suspect a lot of "MVC" apps out there are actually contorted
designs, twisting themselves into the rigid MVC container.

Apache::ASP and Dancer are both policy-free, in that they don't tell you
how to design your app. They just give you a bag of tools and say, "Go
to it!" For the sort of web app that doesn't fit well-established
categories -- blogs, CRUD editors, etc. -- that's exactly what I want.
Other examples are node.js, Nitrogen, Mason+Poet, and straight PHP.

Counterexamples are Rails, Catalyst, Drupal, Zope... These all are more
of a Framework-with-big-F. They are prescriptive, telling you, "Build
your app this way and it will be a lot easier." True only if your app
speaks the framework's design language natively.

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid? [ In reply to ]
On 5/22/2014 11:01, Josh Chamas wrote:
>
> 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.

Routing is more than just an abstraction between the implementation
level and the presentation to the browser. It forces you to consider
your logical URL structure.

My Apache::ASP code just growed, like Topsy. One page at a time, with
no consideration of the interfaces exposed by the other pages. There
was consistency of design only to the extent that there was code
copying, and then in decreasing fashion with respect to time, as the
cloned pages diverged.

As soon as I started developing a system of routes in the Dancer port, I
realized that I had an API. It was sitting there the whole time, never
identified in the Apache::ASP form, but there it was in the Dancer code,
clear as day. Once I'd formally extracted it, I spent a day redesigning
it the way it should always have been. The correct design popped right
out, obvious as a green sky.

This happens because you have to describe your URL structure to Dancer,
one URL per line. Many fit in a single screen of text, so patterns jump
out at you.

Example in Dancer pseudocode:

get '/' => ...
get '/login' => ...
get '/logout' => ...

prefix '/app' => sub {
get 'page1' => ....
get 'page2' => ....
};

prefix '/api' => sub {
del 'foo/:id' => ...
get 'foo/:id' => ...
post 'foo' => ...
put 'foo' => ...

get 'bar/:id' => ...
...same as foo...
};

The story this route structure tells is clear:

1. First you go to the top level page, which perhaps has a Log In link
or button to send you to the /login page.

2. The /login page creates a session and bounces you to /app when you
log in successfully.

3. There's a button or link somewhere that sends you to /logout, which
destroys your session and sends you back to / or /login.

4. The app does CRUD-y things to "foo" and "bar" objects through
/api/{foo,bar}, creating via PUT, reading via GET, updating via POST,
and deleting via DELETE. GET and DELETE require a record ID to tell the
handler what to operate on, while PUT and POST must be fairly complex in
what they will accept, so that the parameters cannot be marked as
required in the route structure.

It's kind of like that Fred Brooks quote, "Show me your flowcharts and
conceal your tables, and I shall continue to be mystified. Show me your
tables, and I won’t usually need your flowcharts; they’ll be obvious."

> 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?)

I don't think so. I believe a minimum-effort Apache::ASP Plack port
would have only one feature relative to Apache::ASP v2, that being web
stack independence. From your perspective, the big difference is that
you have to replace all the mod_perl Apache2::Foo stuff with Plack/PSGI
equivalents.

To get a handle on what routing does for Dancer, say:

$ sudo cpanm Dancer
$ dancer -a foo

This generates a complete, self-contained sample app, suitable for
hacking on directly. That is to say, the file and directory structure
it generates is suitable for production use.

The routing structure is in foo/lib/foo.pm. You also use this file to
define hooks, which are roughly equivalent to global.asa event handlers
in Apache::ASP. Script_OnStart is the same as Dancer's "before" hook,
for example. There is no direct equivalent of Session_OnStart, but you
can build that into the "before" hook, too. The Dancer equivalent to
the Application_* event handlers is foo/bin/app.pl.

If Apache::ASP were to get a routing system, I don't know that you'd
necessarily want to put it in global.asa. It works well for Dancer, but
perhaps another design would make more sense for Apache::ASP, since
global.asa has historical meaning.

Notice, by the way, that foo/lib gets added to @INC by foo/bin/app.pl.
This solves another problem I had with Apache::ASP, which doesn't like
you to define functions and classes in your *.asp files. You end up
creating *.pm files to hold all reused and complicated code. Where then
do you put those *.pm files so that mod_perl can find them?

In my Apache::ASP app, I ended up installing them into the system's
site_perl directory, and then I could never remember the path to those
files when I had to hand-hack one of these files on a production server
to test a problem fix in the field. With Dancer, the *.pm files are
right there next to the rest of the app.

>> 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! :)

I know you're joking, but RAM on VPSes isn't cheap. 4 GB more RAM in my
colocated box is virtually free. 4 GB of RAM added to my cheap
bare-bones VPS plan adds another $35/mo, or $420/yr, or $2,100 over the
expected lifetime of the server.

There's another advantage of Dancer. By going with a single long-lived
app process instead of forking off Apache children, and by making that
app independent of tubby ol' Apache, we can squeeze our app into much
smaller VPSes and VMs.

In extreme situations, you don't even need a traditional web server.
That "foo" app I had you create above? It contains a perfectly usable
basic web server, listening on port 3000. Run it as root so it can bind
to port 80 instead or port-forward 80 to it, and you've got an entirely
self-contained app.

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid? [ In reply to ]
On Thu, May 22, 2014 at 10:55 PM, Warren Young <warren@etr-usa.com> wrote:

>
> Routing is more than just an abstraction between the implementation level
> and the presentation to the browser. It forces you to consider your
> logical URL structure.
>
> My Apache::ASP code just growed, like Topsy. One page at a time, with no
> consideration of the interfaces exposed by the other pages. There was
> consistency of design only to the extent that there was code copying, and
> then in decreasing fashion with respect to time, as the cloned pages
> diverged.
>
> As soon as I started developing a system of routes in the Dancer port, I
> realized that I had an API. It was sitting there the whole time, never
> identified in the Apache::ASP form, but there it was in the Dancer code,
> clear as day. Once I'd formally extracted it, I spent a day redesigning it
> the way it should always have been. The correct design popped right out,
> obvious as a green sky.
>
> This happens because you have to describe your URL structure to Dancer,
> one URL per line. Many fit in a single screen of text, so patterns jump
> out at you.
>
> Example in Dancer pseudocode:
>
> get '/' => ...
> get '/login' => ...
> get '/logout' => ...
>
> prefix '/app' => sub {
> get 'page1' => ....
> get 'page2' => ....
> };
>
> prefix '/api' => sub {
> del 'foo/:id' => ...
> get 'foo/:id' => ...
> post 'foo' => ...
> put 'foo' => ...
>
> get 'bar/:id' => ...
> ...same as foo...
> };
>
> The story this route structure tells is clear:
>
> 1. First you go to the top level page, which perhaps has a Log In link or
> button to send you to the /login page.
>
> 2. The /login page creates a session and bounces you to /app when you log
> in successfully.
>
> 3. There's a button or link somewhere that sends you to /logout, which
> destroys your session and sends you back to / or /login.
>
> 4. The app does CRUD-y things to "foo" and "bar" objects through
> /api/{foo,bar}, creating via PUT, reading via GET, updating via POST, and
> deleting via DELETE. GET and DELETE require a record ID to tell the
> handler what to operate on, while PUT and POST must be fairly complex in
> what they will accept, so that the parameters cannot be marked as required
> in the route structure.
>
> It's kind of like that Fred Brooks quote, "Show me your flowcharts and
> conceal your tables, and I shall continue to be mystified. Show me your
> tables, and I won’t usually need your flowcharts; they’ll be obvious."
>
>
What you describe looks much like REST.
Is it good? I don't know .I guess it is a matter of taste .
Personally ,I like it sometimes and sometimes I wish it would just let me
do what I want and don't force to do "the right thing".

The possible problem of this approach - you need a reverse routing API.
How do you link to an action in a way that is changeable?
What if you want to change all the /app pages to sit under /app_num1 ?
ROR have a helper methods for this ,call "link " method and ROR looks into
the routing tables and creates the reverse route for you.
I guess Dancer have/should have something similar.

I think it would be better for Apache::ASP to have a minimal routing .
Let say -



> 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?)
>>
>
> I don't think so. I believe a minimum-effort Apache::ASP Plack port would
> have only one feature relative to Apache::ASP v2, that being web stack
> independence. From your perspective, the big difference is that you have
> to replace all the mod_perl Apache2::Foo stuff with Plack/PSGI equivalents.
>
> To get a handle on what routing does for Dancer, say:
>
> $ sudo cpanm Dancer
> $ dancer -a foo
>
> This generates a complete, self-contained sample app, suitable for hacking
> on directly. That is to say, the file and directory structure it generates
> is suitable for production use.
>
> The routing structure is in foo/lib/foo.pm. You also use this file to
> define hooks, which are roughly equivalent to global.asa event handlers in
> Apache::ASP. Script_OnStart is the same as Dancer's "before" hook, for
> example. There is no direct equivalent of Session_OnStart, but you can
> build that into the "before" hook, too. The Dancer equivalent to the
> Application_* event handlers is foo/bin/app.pl.
>
> If Apache::ASP were to get a routing system, I don't know that you'd
> necessarily want to put it in global.asa. It works well for Dancer, but
> perhaps another design would make more sense for Apache::ASP, since
> global.asa has historical meaning.
>
> Notice, by the way, that foo/lib gets added to @INC by foo/bin/app.pl.
> This solves another problem I had with Apache::ASP, which doesn't like you
> to define functions and classes in your *.asp files. You end up creating
> *.pm files to hold all reused and complicated code. Where then do you put
> those *.pm files so that mod_perl can find them?
>
> In my Apache::ASP app, I ended up installing them into the system's
> site_perl directory, and then I could never remember the path to those
> files when I had to hand-hack one of these files on a production server to
> test a problem fix in the field. With Dancer, the *.pm files are right
> there next to the rest of the app.
>
>
> 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! :)
>>
>
> I know you're joking, but RAM on VPSes isn't cheap. 4 GB more RAM in my
> colocated box is virtually free. 4 GB of RAM added to my cheap bare-bones
> VPS plan adds another $35/mo, or $420/yr, or $2,100 over the expected
> lifetime of the server.
>
> There's another advantage of Dancer. By going with a single long-lived
> app process instead of forking off Apache children, and by making that app
> independent of tubby ol' Apache, we can squeeze our app into much smaller
> VPSes and VMs.
>
> In extreme situations, you don't even need a traditional web server. That
> "foo" app I had you create above? It contains a perfectly usable basic web
> server, listening on port 3000. Run it as root so it can bind to port 80
> instead or port-forward 80 to it, and you've got an entirely self-contained
> app.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
>
> For additional commands, e-mail: asp-help@perl.apache.org
>
>
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid? [ In reply to ]
Sorry ,hit a send by mistake.


On Thu, May 22, 2014 at 10:55 PM, Warren Young <warren@etr-usa.com> wrote:

> On 5/22/2014 11:01, Josh Chamas wrote:
>
>>
>> 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.
>>
>
> Routing is more than just an abstraction between the implementation level
> and the presentation to the browser. It forces you to consider your
> logical URL structure.
>
> My Apache::ASP code just growed, like Topsy. One page at a time, with no
> consideration of the interfaces exposed by the other pages. There was
> consistency of design only to the extent that there was code copying, and
> then in decreasing fashion with respect to time, as the cloned pages
> diverged.
>
> As soon as I started developing a system of routes in the Dancer port, I
> realized that I had an API. It was sitting there the whole time, never
> identified in the Apache::ASP form, but there it was in the Dancer code,
> clear as day. Once I'd formally extracted it, I spent a day redesigning it
> the way it should always have been. The correct design popped right out,
> obvious as a green sky.
>
> This happens because you have to describe your URL structure to Dancer,
> one URL per line. Many fit in a single screen of text, so patterns jump
> out at you.
>
> Example in Dancer pseudocode:
>
> get '/' => ...
> get '/login' => ...
> get '/logout' => ...
>
> prefix '/app' => sub {
> get 'page1' => ....
> get 'page2' => ....
> };
>
> prefix '/api' => sub {
> del 'foo/:id' => ...
> get 'foo/:id' => ...
> post 'foo' => ...
> put 'foo' => ...
>
> get 'bar/:id' => ...
> ...same as foo...
> };
>
> The story this route structure tells is clear:
>
> 1. First you go to the top level page, which perhaps has a Log In link or
> button to send you to the /login page.
>
> 2. The /login page creates a session and bounces you to /app when you log
> in successfully.
>
> 3. There's a button or link somewhere that sends you to /logout, which
> destroys your session and sends you back to / or /login.
>
> 4. The app does CRUD-y things to "foo" and "bar" objects through
> /api/{foo,bar}, creating via PUT, reading via GET, updating via POST, and
> deleting via DELETE. GET and DELETE require a record ID to tell the
> handler what to operate on, while PUT and POST must be fairly complex in
> what they will accept, so that the parameters cannot be marked as required
> in the route structure.
>
> It's kind of like that Fred Brooks quote, "Show me your flowcharts and
> conceal your tables, and I shall continue to be mystified. Show me your
> tables, and I won’t usually need your flowcharts; they’ll be obvious."
>
>
What you describe looks much like REST.
Is it good? I don't know .I guess it is a matter of taste .
Personally ,I like it sometimes and sometimes I wish it would just let me
do what I want and don't force to do "the right thing".

The possible problem of this approach - you need a reverse routing API.
How do you link to an action in a way that is changeable?
What if you want to change all the /app pages to sit under /app_num1 ?
ROR have a helper methods for this ,call "link " method and ROR looks into
the routing tables and creates the reverse route for you.
I guess Dancer have/should have something similar.
But having all this in Apache::ASP could be an overkill.

I think it would be better for Apache::ASP to have a minimal routing .
Put your modules in app/lib directory
If you defined a route - look for the method in the module
If not just peek up and .asp file.



> 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?)
>>
>
> I don't think so. I believe a minimum-effort Apache::ASP Plack port would
> have only one feature relative to Apache::ASP v2, that being web stack
> independence. From your perspective, the big difference is that you have
> to replace all the mod_perl Apache2::Foo stuff with Plack/PSGI equivalents.
>

There are Middleware modules that maybe could be useful.
But having Apache::ASP have other options except mod_perl is a big deal.


>
> To get a handle on what routing does for Dancer, say:
>
> $ sudo cpanm Dancer
> $ dancer -a foo
>
> This generates a complete, self-contained sample app, suitable for hacking
> on directly. That is to say, the file and directory structure it generates
> is suitable for production use.
>
> The routing structure is in foo/lib/foo.pm. You also use this file to
> define hooks, which are roughly equivalent to global.asa event handlers in
> Apache::ASP. Script_OnStart is the same as Dancer's "before" hook, for
> example. There is no direct equivalent of Session_OnStart, but you can
> build that into the "before" hook, too. The Dancer equivalent to the
> Application_* event handlers is foo/bin/app.pl.
>
> If Apache::ASP were to get a routing system, I don't know that you'd
> necessarily want to put it in global.asa. It works well for Dancer, but
> perhaps another design would make more sense for Apache::ASP, since
> global.asa has historical meaning.
>
>
Yes,there probably should be another config file.
Web.config is what the .NET have.
And taking the ASP name suggesting MS context this is probably a good
choice.


> Notice, by the way, that foo/lib gets added to @INC by foo/bin/app.pl.
> This solves another problem I had with Apache::ASP, which doesn't like you
> to define functions and classes in your *.asp files. You end up creating
> *.pm files to hold all reused and complicated code. Where then do you put
> those *.pm files so that mod_perl can find them?
>
> In my Apache::ASP app, I ended up installing them into the system's
> site_perl directory, and then I could never remember the path to those
> files when I had to hand-hack one of these files on a production server to
> test a problem fix in the field. With Dancer, the *.pm files are right
> there next to the rest of the app.
>
>
I include them on startup.And have them in app directory.
But this is more of mod_perl not Apache::ASP thing.
Porting should fix those 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! :)
>>
>
> I know you're joking, but RAM on VPSes isn't cheap. 4 GB more RAM in my
> colocated box is virtually free. 4 GB of RAM added to my cheap bare-bones
> VPS plan adds another $35/mo, or $420/yr, or $2,100 over the expected
> lifetime of the server.
>
> There's another advantage of Dancer. By going with a single long-lived
> app process instead of forking off Apache children, and by making that app
> independent of tubby ol' Apache, we can squeeze our app into much smaller
> VPSes and VMs.
>
> In extreme situations, you don't even need a traditional web server. That
> "foo" app I had you create above? It contains a perfectly usable basic web
> server, listening on port 3000. Run it as root so it can bind to port 80
> instead or port-forward 80 to it, and you've got an entirely self-contained
> app.
>
>
Agreed .
For me porting is a priority .
I personally don't know a lot about Plack but if Plack is agreed to be the
way to go volunteer to help.



> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
>
> For additional commands, e-mail: asp-help@perl.apache.org
>
>