[web-devel] Hoogle Advice

[Bardur Arantsson]

On 2011-01-25 02:14, Jeremy Shaw wrote:
> On Mon, Jan 24, 2011 at 4:38 PM, Neil Mitchell<ndmitchell at gmail.com>  wrote:
>
>> I think WAI could be increasingly used - its at a level of abstraction
>> that I quite like. I certainly have other projects which I will
>> probably switch over to WAI/Warp.
>
> I am curious to see how your feelings on this change or stay the same over time.
>
[--snip--]
>
> These are the types of features (and more) that exist in the
> higher-level frameworks like Happstack, Snap, and Yesod. In theory,
> that is the value they add over just using WAI. It is likely that, in
> the future, happstack will not include it's own http backend, but be a
> layer on top of WAI+warp, hyena, or some other low-level WAI-like HTTP
> backend. So, I am curious if the value-added features we provide
> actual provide value :)  One measure of this will be if you end up
> creating similar adhoc functions and structure in your apps.
>
[--snip--]

I'm actually considering using WAI for two of my projects as well. I 
haven't had the time to actually try it, but I'm pretty sure I'll be 
doing it for at least one of these projects.

The first one is hums, a UPnP media server. I've essentially implemented 
the socket listening/accept/etc. bits myself and used the 'http' package 
for the protocol bits. In this particular case there is no need for 
sessions, cookies or anything more advanced than simple request/response 
cycle with the occasional "send file", so it seems WAI would be a great 
fit here. It would be nice to finally be rid of the String-based 'http' 
dependency as well.

The second one *is* a framework (just started, hopefully I'll actually 
finish it) for Rich Internet Applications a la Wicket, Vaadin and Echo3. 
Essentially you (as the framework user) program your application in a 
"magical" monad which turns widgets, components and other logic into a 
combination of browser JavaScript/Ajax calls and server-side logic for 
processing state updates. I think using a low-level API like WAI is also 
quite justified in this case simply to avoid huge dependencies. The only 
thing that I'm likely to have to "reimplement" is a little bit of 
routing (but that's a trivial amount) and some handing of 
cookies/sessions (though I may be able to avoid that in the short term). 
There will also be some autogenerated JavaScript and such, but that's 
such a niche thing that I wouldn't really expect much support from a 
general framework for such a thing anyway.

The thing I'd like to see is really more *framework-independent* code 
for things like session handling, cookie handling, etc. I really like 
the 'http' package for this reason. It does exactly one thing and 
(mostly) doesn't get in the way of whatever else you're trying to do.

Maybe some of this 'generic' stuff could be put in WAI middleware -- 
then at least Neil and I could share that code :).

Cheers,

Bárður