perl-asp mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tsirkin Evgeny <>
Subject Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?
Date Fri, 23 May 2014 09:58:56 GMT
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/  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/
> 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

> Notice, by the way, that foo/lib gets added to @INC by foo/bin/
> 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:
> For additional commands, e-mail:

View raw message