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

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

Expand Messages
  • Warren Young
    May 22, 2014
    • 0 Attachment
      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

      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@...
      For additional commands, e-mail: asp-help@...
    • Show all 13 messages in this topic