[web-devel] IDEA: wai-vhost
Mark Bradley
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.
-barkmadley
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.
>
> Dmitry
>
> 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
>> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/web-devel
>
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
>
More information about the web-devel
mailing list