My priorities: * Make storage and client stuff transparent to server side developer * Use in memory haskell data structures to represent state. + rely on MACID for persistence + no type errors from app/db inconsistency + isolate schema change risk to deserialization from disk + no need for extra mem-cache plumbing! * Atomatic conversion to/from wire format types to haskell data types in my app. Auto-parse/generate JSON/XML/URLEncode. * Scaling should be really really easy * easy integration of multi-protocol services e.g. IRC, SMTP, HTTP in one app. See HPaste and Pass.net. * develop in Haskell. -Alex- On Thu, 5 Apr 2007, Paul Brown wrote:
Let me through Avi Bryant's recent slides into the conversation:
http://smallthought.com/avi/etech.pdf
Some things that I think, some of which overlap with what Avi's saying:
1) Programmatic generation of content is good. Interaction with designers can be managed simply -- select CSS as the primary means of customizing display, settle on prototype HTML for the designers to work with, generate the HTML programmatically to that prototype as a spec.
2) Templating is ugly. Debugging and testing are difficult. Templating is antipodal to separation of concerns.
I'd like us to brainstorm on a couple of topics:
A) How do we leverage what is special about Haskell -- laziness, types, purity -- to create an effective and simple web framework?
B) What's wrong with existing web frameworks (RoR, straight JSP, PHP, etc.)?
For my money, the things that are wrong with RoR and friends is that they let you write really awful software -- even *force* you to do so by the decomposition into templates, controllers, etc. Which brings us back to question A.
-- paulrbrown@gmail.com http://mult.ifario.us/ _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel