Opened 11 years ago

Closed 10 years ago

#15 closed enhancement (fixed)

Bearmail GUI mod_perl support

Reported by: Vincent Caron Owned by: zecrazytux
Priority: minor Component: Bearmail
Keywords: Cc:

Description

We plan to host a Bearmail GUI demo. While CGI is fine for development (especially since bearmail is still quite light), that would be so "1.0" and inefficient as a hosting solution.

Here is the time to add mod_perl support. CGI::App supports it, that's maybe a simple as documenting the required Apache config blurb, I don't know.

Internal note: we'll fit the demo as http://bearmail.bearstech.com/ in our 'Otto' server.

Change History (15)

comment:1 Changed 11 years ago by zecrazytux

(In [497]) Added mod_perl support, see #15

comment:2 Changed 11 years ago by zecrazytux

Status: newassigned

I've been fighting with mod_perl and C::A for very long hours... Finally got it working with a few limitations...

C::A has a native mod_perl support, but subclassing its dispatch_args() method is necessary in order to instantiate the C::A dispatcher with custom arguments.

With mod_perl, we cannot use cwd() to get the Bearmail path. We may use the environnement variable 'SCRIPT_FILENAME'... I assumed the BEARMAIL environnement variable would be set (easily doable with PerlSetEnv? in the apache2 configuration)

Also, I could'nt host bearmail on the root of the vhost, because this way static file names are interpreted as applications/runmodes with C::A. I've tried to add a <Files> section with a set-handler None but it does not do the trick. So, static files must be served in a parent directory... Or has anyone an idea about this glitch ?

my apache2 conf looks like this:

<VirtualHost *:80>
	DocumentRoot /bearmail/bearmail/public
	PerlModule BearMail::Dispatch
	<Location /bearmail>
          SetHandler perl-script
          PerlHandler BearMail::Dispatch
	  PerlSetEnv BEARMAIL /bearmail/bearmail
	</Location>
</VirtualHost>

comment:3 Changed 11 years ago by Vincent Caron

C::A has a native mod_perl support, but subclassing its dispatch_args() method is necessary in order to instantiate the C::A dispatcher with custom arguments.

Could we also re-use BearMail::Dispatch for the CGI case ? There's some duplicate code in source:/bearmail/bin/bearmail.cgi now, this should be enough (see below):

use BearMail::Dispatch;
BearMail::Dispatch->dispatch();

There should not be a lot of magic to make BearMail::Dispatch work for both CGI and mod_perl cases (?)

With mod_perl, we cannot use cwd() to get the Bearmail path. We may use the environnement variable 'SCRIPT_FILENAME'... I assumed the BEARMAIL environnement variable would be set (easily doable with PerlSetEnv?? in the apache2 configuration)

True, BEARMAIL should be set. However, guessing the path from the script itself looked correct in most cases and very handy. In other words, falling back on cwd() looked "DWIM", so I added it. I wouldn't be shocked by another hack based on SCRIPT_FILENAME.

Long term view: we should really pass a BEARMAIL_CONF||=/etc/bearmail/bearmail.conf env var (and only this one), then define all other paths in the conf file. For instance the template path would be set to /usr/share/bearmail/web/template in a default RMP/deb conf file... And so on.

Also, I could'nt host bearmail on the root of the vhost, because this way static file names are interpreted as applications/runmodes with C::A

I'm not surprised, it's the same with many schemes. You need a convention to distinguish application URLs and static files URLs within your httpd:

  • In the PHP world, you test -f $docroot/$url: if it exists it's static, if not it is passed to the app. Slight risk of name collisions but very easy to understand and use.
  • In some worlds you reserve an URL space (/static/) or a distinct subdomain (static.app.com), but you need to be firm on the convention at every level (templates, URL generations, etc)

Both solutions work and can be implemented with any httpd. The second is preferred for large scaling where you want to serve static ressource from a distinct domain to 1/ parallelize dl, 2/ spare the Set-Cookie, but it needs DNS tweaking. For the URL namespace reservation, it's actually better backwards: have an /app/ namespace with a cookie bound to path=/app/, so the browser does not send useless Set-Cookie for static requests. That's you actually did in your Apache sample above :)

What do mod_perl site do at large ? Typepad ? Catalyst based ?

comment:4 Changed 11 years ago by zecrazytux

(In [506]) Refactoring of bearmail.cgi using BearMail::Dispatch Improved the documentation Another step towards bearmail packaging, using a single configuration file and an optional environment variable See #15

comment:5 Changed 10 years ago by zecrazytux

Resolution: fixed
Status: assignedclosed

comment:6 Changed 10 years ago by Vincent Caron

Resolution: fixed
Status: closedreopened

I need to fix a few things... Commits comming.

comment:7 Changed 10 years ago by zerodeux

(In [512]) s/BearMail::Dispatch/BearMail::Web::Dispatch/ + removed +x bit, see #15

comment:8 Changed 10 years ago by Vincent Caron

And [513]: Better missing cfg(backend) handling

comment:9 Changed 10 years ago by zerodeux

(In [514]) Added mod_perl dev hint to automaticlly reload modules or you go crazy, see #15

comment:10 Changed 10 years ago by zerodeux

(In [516]) Backend::Files error handling fixes, see #15

lib/BearMail/Backend/Files.pm: croak() on missing cfg(mailmap)

lib/BearMail/Backend/Files.pm: stat() after open()+flock() so we have proper

error reporting (file missing, etc) and no race conditions

lib/BearMail/Backend/Files.pm: fixes funy Package name mangling, we _need_ the Bearmail:: prefix. While I'm at it, cfg(backend) only needs the actual backend name (eg: Files) and we explictly instantiate it. No ugly $backend->new() trick even if $backend is sanitized.

UPDATE your bearmail.conf:backend param (strip 'Backend::' prefix).

comment:11 Changed 10 years ago by Vincent Caron

Resolution: fixed
Status: reopenedclosed

Et, ops [518].

comment:12 Changed 10 years ago by zecrazytux

(In [526]) Fixed to configuration file to reflect changes made in 516, see #15

comment:13 Changed 10 years ago by Vincent Caron

Resolution: fixed
Status: closedreopened

CGI::App doc says: "For more information on using CGI::Application with mod_perl, please see our website at http://www.cgi-app.org/, as well as CGI::Application::Plugin::Apache, which integrates with Apache::Request."

Did you look at CGI::Application::Plugin::Apache ? Maybe we need it, and at least there's some specific mod_perl 2 information.

comment:14 Changed 10 years ago by zecrazytux

(In [531]) Turned Backend::Files into an object oriented module, see #10 and #15 This would fix the problem of consistency when used with mod_perl2.

comment:15 Changed 10 years ago by zecrazytux

Resolution: fixed
Status: reopenedclosed

Fixed in 531

Note: See TracTickets for help on using tickets.