[web-devel] Hoogle Advice
spam at scientician.net
Tue Jan 25 08:33:37 CET 2011
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.
> 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.
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
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).
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 :).
More information about the web-devel