Re: [Haskell-cafe] Haskell Web Framework
John A. De Goes wrote: The best approach is to push as much functionality into the client as possible. The ideal server-side framework consists of nothing more than a permissions-based interface to persistence and network services. That's it. Everything else is done on the client side, in JavaScript. +1 This is the conclusion I have come to in building collaborative Web applications. I agree that there seems to be a gap here in the Haskell Web frameworks people are building. What this means is that effort is probably best directed at Yhc/JavaScript and similar projects, which compile Haskell to JavaScript for execution on the client. I do not believe compiling Haskell to ECMAScript/JavaScript is a productive avenue. There is too much pain in trying to abstract away the JavaScript model only to write everything in Haskell and end up with worse performance as a reward. There is very little wrong with ECMAScript if people would only learn it properly and play to its strengths instead of trying to turn it into things it is not. Treating ECMAScript as a compiler target language will be a win eventually, I expect, but not by compiling from Haskell. Haskell could certainly play a role, e.g. as an implementation language for ES-to-ES or DSL-to-ES compiler writers. Michael Snoyman wrote: That's great in theory, but then you end of with inaccessible web sites, This doesn't have to be true. You can do quite well today if you are careful, and ARIA will resolve the remaining issues. those without Javascript are left out in the cold, Yes. JavaScript is a requirement for the full functionality of the modern Web. and search engines won't index you. This also isn't true if it's done right. It's almost always done wrong, but that's just ignorance and incompetence, not any inherent limitations of the technology. Follow correct principles of Web architecture and you can do fine with search engines, even if you rely on JavaScript to provide a UI. -- Michaeljohn Clement ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
I am very interested in this work. One thing missing is support for all HTTP methods, not just those in RFC 2616. As-is, something like WebDAV cannot be implemented. That probably means requestMethod should be a (Byte)String. What about something like sendfile(2) available on some platforms? To allow the server to make use of such optimizations, how about an optional alternative to the enumerator? Perhaps the app can optionally pass a path or an open fd back to the server in place of an enumerator, which allows servers to do any kind of buffering optimizations, etc, that they may know about, as well as using any platform-specific optimizations like sendfile. -- Michaeljohn Clement ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
Adam Langley wrote: On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell [EMAIL PROTECTED] wrote: * Using a different set of data types would work better. Give that this is Haskell, I'd suggest more types ;) HTTP headers aren't just strings and, at the risk of tooting my own horn, I'll point to the Headers structure in [1]. That is one of the things I don't like about Network.HTTP, which also enumerates header fields. It is inconvenient to have to look up the names in the data type, when the standard field names are already known, and it makes using non-RFC2616 headers less convenient. Automatic parsing of header fields also makes unusual usage inconvenient, (for example the Range header support in [1] is a profile of RFC2616.) I think those kinds of features belong in frameworks; they will be more of an annoyance than a help to anyone that is writing to the WSGI layer. Likewise, URLs have lots of structure that should just be handled in one place [2] Yes, I think should be parsed to the level of granularity specified by RFC 2616 (i.e. scheme, host, port, path, query string) and anything more (like parsing query strings) should be handled by frameworks. [1] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/Marshal.hs [2] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/URL.hs AGL -- Michaeljohn Clement ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] some simple proof exercises
http://www.thenewsh.com/%7Enewsham/formal/problems/set1.html In P2 there is a typo: 8: Assume: xs ++ [] = zsindhypothesis ^^ I know very little Haskell but the proofs were nonetheless easy enough to follow. HTH, Michaeljohn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
