I'd first like to thank everyone who has replied so far. Your feedback has been invaluable.
I'm going to try and address some of the issues people have raised. If I've missed any big ones, feel free to shout louder :) @Joost Could you send me an email with the i18n patches you had to make to Compojure/Ring? @Chas I think we probably need a high-level way of exposing a type as a HTTP resource. I haven't thought about this much, but it's certainly a hole that isn't quite filled by currently available libraries. @Chas, @Brian, @Brenton Deployment is also an issue. Perhaps we need a Leiningen plugin that would automatically generate an AOTed HttpServlet, given a :handler key in defproject that designates the main handler function. Another option is to bypass the whole idea of Java servlet containers and devise some lightweight Clojure solution. I guess some people will like that idea, whilst others will shudder at the idea of reinventing a well-used wheel. @Hugo I agree that a standard authentication and authorization library would be good. With OpenID, OpenAuth, etc. authentication is becoming quite complex, and login pages are becoming quite uniform. It would be nice to have some middleware that would automatically provide this sort of thing. Named routes may be something I could integrate into Compojure. I'd have to think of a good way of doing it. @Adrian One thing Ring and Compojure are lacking are some good benchmarks. I'll have to see about making some, unless anyone wants to volunteer? @Jimmy, @Chas, @Sean Websockets/Comet is something that has been mentioned to me a few times. Websockets are a separate protocol to HTTP, and Comet is essentially a separate protocol, even if it uses HTTP as a transport layer. So in the past, my opinion is that normal HTTP should be handled by Ring, and Websockets/Comet should be handled by something different. However, it occurs to me that whilst Websockets and Comet are arguably not HTTP, they do start out with a normal-looking HTTP request. I wonder if Ring could accept this initial request, but instead of returning a standard response map, it returns a message-handling function. I'll think about this, then bring it up on the Ring group for further discussion. @Wilson, @Daniel, @Mark E Clojure web development is shaping up to be made up of many small, interchangeable parts. On the whole, I think this is a good thing. I don't like the idea of monolithic web frameworks, continually reinventing the same wheels (routes, templates, ORM). My goal for Clojure web development is near total interoperability. But at the same time, it's good to be able to pick something up that integrates all these small parts together. I think eventually we'll see larger frameworks emerging for Clojure that just tie a bunch of low-level libraries together. But I think we're a little way off that goal. @Wilson, @Brenton, @j-g-faustus, @Brian, @pavelludiq I've also started writing a Clojure Web Development book. One of the problems of having lots of small libraries is that its hard to get an overview of how one should proceed. The Clojure Web Development book is an effort to take the reader through the Clojure web development ecosystem, starting with Ring, but also later covering Compojure, Hiccup, Enlive, Moustache, Sandbar and others. I envision this as being similar to the Git community book [http://book.git-scm.com/]. I've started a Google document for it, which you can view here: https://docs.google.com/Doc?docid=0AQqGP1CDN0uIZGhmZjJmcGZfMjNjNHIycGZu&hl=en At the time of writing, it's in a ***very*** rough state. If anyone wants to help me out, I'll send them a read-write link they can use to contribute. When the book is more complete, I'll divide it up into web pages and put it in a GitHub repository. @Mark S Logging is something I've been very interested in at various points in the past, usually when an application goes wrong in production and I have to figure out what went wrong! I think we need to discard the notion that logs should be timestamped strings outputted to a file. Instead, I think they should be hash-maps we send to a logging server, which then stores them in a database. You could then visit the database and say "Show me all exceptions that occurred for user X". You could then select the field you wanted and say "Show me all log messages that occurred within the context of the same request as this exception". This is something that would have saved me a lot of pain in the past. You've gotten me thinking of writing something like this, perhaps using MongoDB or Redis to store the documents, and Compojure to write a nice web interface for searching/configuring. @Martin I've been thinking on and off about how to bind data to a set of routes. I'll let you know if I come up with anything, and suggestions are always welcome. I think Allen's "Turtles all the way down" post in the Compojure group is thinking along the right lines. @Howard Exception reporting could be better, I think. Clojure in general tends to have pretty tangled stacktraces, but perhaps that's just because it's difficult to distinguish between my libraries and clojure.core where the exception invariably bubbles up from. Improvements to the Ring stacktrace middleware might help. Perhaps also something that automatically logs stack traces. @Mark E Hosting facilities will probably improve in future, but I suspect it'll be a while. I'd personally like something like Heroku, but I don't think the demand is there to sustain a service like that. I hope this reply was comprehensive enough. There are a lot of really useful replies in this thread. - James -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
