Loading ...
Sorry, an error occurred while loading the content.

2343Re: Migrate existing Apache::ASP code from mod_perl to mod_fcgid?

Expand Messages
  • Tsirkin Evgeny
    May 23, 2014
    • 0 Attachment
      Sorry ,hit a send by mistake.


      On Thu, May 22, 2014 at 10:55 PM, Warren Young <warren@...> 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@....org

      For additional commands, e-mail: asp-help@...


    • Show all 13 messages in this topic