> It seems to me that Ring's approach works well if there's the > possibility of implementing Ring using technology other than Servlets. > In this case, it makes sense for Ring to act as a minimum common > interface. But if this isn't your goal, then you're just removing > functionality for aesthetic reasons. > > I'm in two minds about this. I agree that session handling and > parameter parsing don't belong in a functional interface for HTTP > handling. But on the other hand, they certainly do belong in a > functional interface to the Java Servlet spec (flawed as that spec may > be). If you're attempting the former, then I agree with your decision. > If it's the latter, I think you should be more pragmatic.
For Ring, the HttpServlet API is a means to an end, not an end in itself. The interface that Servlets present for parameter parsing and session handling are too flawed to merit their inclusion as default choices for Ring apps and the binding of Ring to Servlets in general. Thus I'd like to see Ring applications remain decoupled from the Servlet API, while Ring handlers can leverage Servlet functionality internally to implement for these apps the cleanest HTTP API possible. --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
