[web-devel] On the state of Haskell web frameworks
greg at gregorycollins.net
Mon Mar 15 21:18:33 EDT 2010
Jeremy Shaw <jeremy at n-heptane.com> writes:
> On Mon, Mar 15, 2010 at 5:38 PM, Gregory Collins <greg at gregorycollins.net> wrote:
> We need pluggable *applications* (blog, CMS, RSS feed generation,
> administrative panels, forum, wiki, caching, user management, etc) that
> understand how to talk to each other --- expecting "plug and play"
> compatibility between frameworks on this level, when there's no
> consensus on the *primitives*, is a pipe dream. The first framework that
> cracks this particular nut, in a way that makes it easy and pleasurable
> for people to build web apps that perform, is going to gain a lot of
> traction. Code talks.
> I have been working on this in the happstack framework. Specially, the
> idea of making possible for you to write a new application by
> combining several libraries writing by different authors.
> The first issue is that the libraries need to have unique URLS that
> can not collide with each other. If two libraries expect to be able to
> handle, "http://localhost/submit", that will never fly.
We're planning on handling this in Snap by doing what Java servlets do:
you hang your component (our limp-pun code name for these is "Snaplets")
somewhere on a portion of the URL tree. If you hang a servlet on "/foo"
and give it request "/foo/frobnicate", the server tells you the servlet
context path is "/foo" and the request path is "/frobnicate". To me this
is a smart and sensible approach.
> So one aim of URLT was to ensure that when you combined different
> modules together, the URLs remained unique.
I'm not sure I'd want to use this, there's too much data being encoded
at the type level here. I don't understand the fetish for wanting to
verify links with a typechecking scheme anyhow; if you make the
simplifying assumption that component authors can keep it together
enough to keep their intra-component links organized, the only problem
you really need to worry about is linking from one component into
another. (I.e. "zazzle 1.7 broke all my internal links!")
To me it seems more natural to solve that issue by asking zazzle to give
you a link to one of its resources; i.e. take a pull vs. a push
approach. If the code to pull the link to zazzle goes missing it will be
obvious and you can fail loudly instead of silently. I don't know about
you guys, but I think that level of assistance is enough for me -- do I
have to run my website through a proof assistant?
Gregory Collins <greg at gregorycollins.net>
More information about the web-devel