[web-devel] IDEA: wai-vhost
barkmadley at gmail.com
Tue Nov 23 14:23:16 CET 2010
As an optional feature i see no downside. Obviously if you would want
to use this feature you have to pick compatible applications.
sent from an internet enabled device
On Tue, Nov 23, 2010 at 11:11 PM, Dmitry Olshansky
<olshanskydr at gmail.com> wrote:
> 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.
> 2010/11/23 Michael Snoyman <michael at snoyman.com>
>> 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
>> 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.
>> web-devel mailing list
>> web-devel at haskell.org
> web-devel mailing list
> web-devel at haskell.org
More information about the web-devel