Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: Re: Re: mod_perl & TT2 Architecture

by EvdB (Deacon)
on May 25, 2004 at 17:22 UTC ( #356301=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: mod_perl & TT2 Architecture
in thread mod_perl & TT2 Architecture

Well - it looks prettier for a start...

One advantage is that if the modules are distributed to others then the amount that they need to type into the httpd.conf file is reduced. It also means that the module authors get control of the url layout and so can change it without ever changing the httpd.conf file - ie easy upgrades. For something like a drop in blog or mail solution this would be vital.

Another reason is that you can then ensure that the user has jumped through some hoops before letting them get as far as the next modules. This could be authenticating them or setting up variables based on their preferences.

Also the layout does not need to come from a hash, it could come from an XML file. This opens up the possibility of allowing plugins to be added to a site automatically - the plugin would register itself in the XML and the handler would then know that it could dispatch to it. There is more needed to make this work (ie modding templates etc) but it allows for it.

Finally it allows the _possibility_ of running the same code as a plain CGI (although the $r would have to be faked up). This would not be trivial but there would be one less obstacle.


Comment on Re: Re: Re: mod_perl & TT2 Architecture
Re: Re: Re: Re: mod_perl & TT2 Architecture
by perrin (Chancellor) on May 25, 2004 at 17:44 UTC
    I respect your opinion, but I disagree with you on nearly all of this.

    One advantage is that if the modules are distributed to others then the amount that they need to type into the httpd.conf file is reduced.

    You can't get much shorter than adding Include myproject.conf to your httpd.conf file.

    It also means that the module authors get control of the url layout and so can change it without ever changing the httpd.conf file - ie easy upgrades

    Anyone who is allowed to write a module that will run under mod_perl should be allowed to change the conf file. The amount of damage that can be done is equivalent, so responsibility should be the same.

    Another reason is that you can then ensure that the user has jumped through some hoops before letting them get as far as the next modules. This could be authenticating them or setting up variables based on their preferences.

    I normally structure my apps to run some common setup stuff before handling any request. This has nothing to do with the conf file -- you just make your apps use a common base, like CGI::Application or Maypole. Auth stuff, on the other hand, belongs in the conf file. Apache has a built in phase for dealing with it that allows you to easilly change the auth system and permissions for specific apps. This is much harder to modify if you shove it all into your main application code instead.

    Also the layout does not need to come from a hash, it could come from an XML file.

    How would that be better than httpd.conf? It's not quite XML, but it's close. It's actually less verbose than XML would be.

    Finally it allows the _possibility_ of running the same code as a plain CGI

    It actually makes this no easier or harder than it would be if you did the mapping in the conf file. You can map to CGI scripts just as easilly as you can to handlers.

    Finally, there is value in doing things the standard way. No one on earth knows how to set things up using the private configuration method you just invented. Tons of people know how to set up an Apache conf file. That is valuable in itself.

      This debate could go on for ages. Let me say that I do agree with you and am playing devil's advocate to some extent. The point I am trying to make is that in some situations the standard way of doing things is not always the best.

      I'll try to get this across by looking only at the first point - that putting the dispatch stuff in the main module can be a good idea for 'blackbox' apps.

      The imaginary scenario: I have a blog app which runs under mod_perl. It is intended that the sys admin need only run perl-MCPAN -e 'install UberBlog' and then add this to their httpd.conf file:

      <Location /foo/bar/blog/> SetHandler perl-script PerlHandler UberBlog::Dispatcher PerlSetVar UberBlog_DSN "dbi:Pg:dbname:uberblog" </Location>

      Even the most novice sys-admin should be able to do that, and would then be able to forget about it as long as it all worked. When it comes to upgrading all she need do is run perl -MCPAN -e 'install UberBlog' again and it will all work.

      If the user wants to dig into the internals then the name of the handler should give them a good clue as where to start.

      All of the above could have been put into 'uberblog.conf' and then 'Include'd as you suggest, but then this file would have to be located on the filesystem somewhere and it would not be possible to upgrade it when the module got upgraded. This adds complexity that the user does not want. It could also couse real trouble if another admin on the same machine decides to upgrade the modules.

      I think that there is merit in putting a fair amount of stuff in the main handler and running the show from there. There is also plenty of merit in not doing that though... I hope have have won you over to some extent with regards to the above scenario.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://356301]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (9)
As of 2014-12-21 06:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (104 votes), past polls