Re: Re: Re: mod_perl & TT2 Architecture

[EvdB]

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.

[perrin]

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.

[EvdB]

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.