On Tue, Jan 25, 2011 at 8:29 PM, Chris Smith
On Tue, 2011-01-25 at 20:10 +0200, Michael Snoyman wrote:
That's one of the main reasons I've designed Yesod and WAI the way I have. By splitting the project up into so many pieces (Hamlet, Persistent, authenticate, etc), users get to pick and choose exactly what they want.
Yes. Happstack is the same way.
Yes, and I'm a fan of that. I just wish that other frameworks (cough, cough) could take a similar approach.
What parts of Snap would you like to see split out into separate projects? Heist is completely independent of Snap. And snap-server is already a separate package from snap-core that handles the low-level HTTP stuff, though perhaps the module boundary isn't exactly where and like you're accustomed to. As of now, the Snap project doesn't really have an endorsed answer for persistence; if Snap ever decides that it needs its own new entry into persistence frameworks (which I don't yet see a reason for; there's really no need for all of us to reinvent everything!), I have no doubt it'll be split into its own package as well.
Granted, there is an umbrella mechanism for pulling these things together and making them interoperate in the same application -- that's the extensions mechanism. But I'd consider it a flaw if an extension actually contained substantial independent ideas; the model Snap is following thus far is to provide functionality with a natural interface, and *also* an extension to help integrate it together.
Just my thoughts; not speaking for anyone else!
Sorry, you're right: Snap *has* done a good job of releasing a number of auxiliary packages: attoparsec-iteratee, Heist, the upcoming xmlhtml package. I should not have implied otherwise. Without reopening an old debate, I'm referring to the avoidance of WAI. Also, I've heard a number of people (yourself included) touting how good the routing mechanism is in Snap. I know routing is fairly central to a framework, so it may not be possible to separate out. But Happstack and Yesod are both able to use web-routes, it would be nice to see a similar concept from Snap. Looking back at the snap-core and snap-server packages, it *definitely* seems like I misspoke: most functionality that *could* be split off seems to already have been. My apologies. Michael