Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
Sorry ,hit a send by mistake.
On Thu, May 22, 2014 at 10:55 PM, Warren Young 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 "befo
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
On Thu, May 22, 2014 at 10:55 PM, Warren Young 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 c
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
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, b
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
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-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
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-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
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 mailto:j...@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
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
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 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
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
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
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
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
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
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-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org ---
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
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-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org
Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
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-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org - To unsubscribe, e-mail: asp-unsubscr...@perl.apache.org For additional commands, e-mail: asp-h...@perl.apache.org
