
Just thought I'd throw out an idea I've been bouncing around and see if anyone would be interested in either using or implementing it. Basically, it allows multiple WAI applications to be run as a single app and switch which app responds to a request based upon the Host, the same way virtual hosting works in web servers like nginx, Apache or lighttpd. I would imagine the type signature would look something like: vhost :: [(String, Application)] -> Application -> Application The first argument would be a list of applications and their respective virtual hosts (this would probably be better as a Map for performance, kind of irrelevant at this point). The second argument would be the default application to run when none of the vhosts match. This could even just be an app that always returns a 404. It returns a new application handles all of this transparently. I can see two immediate uses: * Instead of running a whole bunch of WAI fastcgi processes on a server, you could run just a single process that automatically deals out requests to the right app. This would save on memory usage, especially when your apps are all sharing the same Haskell libraries. * Instead of needing a dedicated web server like nginx to handle vhosting, you could use the Snap handler with this and be running a pure Haskell stack. Advantage would be easier maintenance, plus better performance from cutting out the middleman. At this point, it's just an idea. I don't think it's hard to implement, but I wouldn't mind some feedback first. And if someone else wants to take a crack at it, please speak up! I wouldn't mind having one less package to maintain. Michael

So you will have one executable for totally different applications?
I think there could be some problems on compilation with different
package-versions and/or the same module-names from different packages.
I don't know could it be resolved painlessly or not.
Dmitry
2010/11/23 Michael Snoyman
Just thought I'd throw out an idea I've been bouncing around and see if anyone would be interested in either using or implementing it. Basically, it allows multiple WAI applications to be run as a single app and switch which app responds to a request based upon the Host, the same way virtual hosting works in web servers like nginx, Apache or lighttpd. I would imagine the type signature would look something like:
vhost :: [(String, Application)] -> Application -> Application
The first argument would be a list of applications and their respective virtual hosts (this would probably be better as a Map for performance, kind of irrelevant at this point). The second argument would be the default application to run when none of the vhosts match. This could even just be an app that always returns a 404. It returns a new application handles all of this transparently.
I can see two immediate uses:
* Instead of running a whole bunch of WAI fastcgi processes on a server, you could run just a single process that automatically deals out requests to the right app. This would save on memory usage, especially when your apps are all sharing the same Haskell libraries.
* Instead of needing a dedicated web server like nginx to handle vhosting, you could use the Snap handler with this and be running a pure Haskell stack. Advantage would be easier maintenance, plus better performance from cutting out the middleman.
At this point, it's just an idea. I don't think it's hard to implement, but I wouldn't mind some feedback first. And if someone else wants to take a crack at it, please speak up! I wouldn't mind having one less package to maintain.
Michael _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

As an optional feature i see no downside. Obviously if you would want
to use this feature you have to pick compatible applications.
-barkmadley
sent from an internet enabled device
On Tue, Nov 23, 2010 at 11:11 PM, Dmitry Olshansky
So you will have one executable for totally different applications?
I think there could be some problems on compilation with different package-versions and/or the same module-names from different packages. I don't know could it be resolved painlessly or not.
Dmitry
2010/11/23 Michael Snoyman
Just thought I'd throw out an idea I've been bouncing around and see if anyone would be interested in either using or implementing it. Basically, it allows multiple WAI applications to be run as a single app and switch which app responds to a request based upon the Host, the same way virtual hosting works in web servers like nginx, Apache or lighttpd. I would imagine the type signature would look something like:
vhost :: [(String, Application)] -> Application -> Application
The first argument would be a list of applications and their respective virtual hosts (this would probably be better as a Map for performance, kind of irrelevant at this point). The second argument would be the default application to run when none of the vhosts match. This could even just be an app that always returns a 404. It returns a new application handles all of this transparently.
I can see two immediate uses:
* Instead of running a whole bunch of WAI fastcgi processes on a server, you could run just a single process that automatically deals out requests to the right app. This would save on memory usage, especially when your apps are all sharing the same Haskell libraries.
* Instead of needing a dedicated web server like nginx to handle vhosting, you could use the Snap handler with this and be running a pure Haskell stack. Advantage would be easier maintenance, plus better performance from cutting out the middleman.
At this point, it's just an idea. I don't think it's hard to implement, but I wouldn't mind some feedback first. And if someone else wants to take a crack at it, please speak up! I wouldn't mind having one less package to maintain.
Michael _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
participants (3)
-
Dmitry Olshansky
-
Mark Bradley
-
Michael Snoyman