[web-devel] Hoogle Advice

[Michael Snoyman]

On Tue, Jan 25, 2011 at 9:33 AM, Bardur Arantsson <spam at scientician.net> wrote:
> 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 :).

I've been making a big push to get framework-agnostic code separated
out into separate packages wherever possible. For your case you may
want to look at the cookie and clientsession packages. Additionally,
you may want to consider using blaze-html for the HTML generation, or
even Hamlet.

I'd be interested in hearing more about how you are planning on
implementing this framework. Yesod already provides built-in support
for widgets, though so far I have been very conservative about
including direct Ajax features. For the most part, it is used for
providing form controls that do validation. However, there's no reason
it *couldn't* be used for Ajax.

Following my normal sets of advice, I would recommend that any
component that you build that is not intrinsically tied to your
framework be released as a separate package so we can all benefit and
share resources where relevant. And if you have questions/requests on
the WAI side, just let me know.

Michael