Sven, I like this idea. Thanks.
-Hari On Wednesday, May 6, 2015 at 11:46:35 AM UTC-7, Sven Richter wrote: > > Hi, > > I had a short chat with Dmitri (the owner of luminus) and we both agreed > that this is a good plan. I just don't have much time right now (family > things), but as soon as there is more I will develop a prototype, > integrating the features of closp and closp-crud into luminus and make them > available as a luminus profile. > > Best Regards, > Sven > > Am Mittwoch, 6. Mai 2015 18:08:03 UTC+2 schrieb Sven Pedersen: >> >> Hey Sven, >> It looks to me like you could really polish the +auth part and integrate >> most of that part of closp into Luminus. I'd be happy to help with that. >> Then you could make a +closp that depends on +auth and build the UI parts, >> etc. Having a working +auth with a default db configuration, possibly with >> both yesql and korma as back end options, would make auth/authz trivial to >> set up. Then you could also focus on what makes closp unique. >> --Sven >> >> On Tuesday, May 5, 2015 at 1:27:21 AM UTC-4, Sven Richter wrote: >>> >>> Hi Dmitri, >>> >>> When I was building closp I was taking luminus as the base for it with >>> some minor adoptions. I just had a look at the website of luminus and saw >>> the massive amount of work you put into the documentation again. If that >>> sounds reasonable for you I'd like to try to move closp and closp-crud to >>> luminus as an opionated part of it. >>> So if you call lein new luminus projectname +closp you will basically >>> get what you get now with closp. You can look here for the additions: >>> https://github.com/sveri/closp. >>> I would like to maintain that "branch". >>> >>> I am not sure if that will work out the way I think, but I'd like to >>> evaluate it at least. It would be nice to have a common base and a common >>> documentation for it. >>> >>> Best Regards, >>> Sven >>> >>> Am Dienstag, 5. Mai 2015 02:38:41 UTC+2 schrieb Dmitri: >>>> >>>> As others have pointed out the comparison isn't really valid. Luminus >>>> intentionally aims to leverage existing libraries that are maintained >>>> independently whenever possible. I've been doing web dev with Clojure for >>>> the past 4 years and overall I do prefer the approach of using composable >>>> libraries over monolithic frameworks. With the Clojure web stack it's much >>>> easier to tell what's actually happening during the request/response >>>> lifecycle as things tend to be explicit. With frameworks like Rails a lot >>>> of stuff happens implicitly and requires a lot of in depth knowledge to >>>> work with effectively. >>>> >>>> However, there are a some downsides to the libraries over frameworks >>>> approach as well. The biggest issue is that it's difficult to track what >>>> libraries are actively maintained and which ones play nicely together. >>>> Since most libraries are maintained by individuals it's common for them to >>>> become abandoned. Another problem is that each app becomes a unique >>>> snowflake since there aren't a lot of established patterns for structuring >>>> them. Finally, security is an issue for Clojure web apps as a lot of it >>>> done in rather ad hoc fashion. While this works great for people who are >>>> well versed in the Clojure web ecosystem it's a huge barrier for newcomers. >>>> >>>> I think that the best way to address the problem is via organizations >>>> where related projects are maintained by groups of contributors. This >>>> helps >>>> discovery of projects, and it helps spread the burden of maintenance for >>>> them. This approach is already working in the wild on GitHub with Ring, >>>> Reagent, and Luminus orgs. Meanwhile, Leiningen templates are a great way >>>> to provide reasonable defaults for different types of applications and can >>>> be used to address issues such as security. >>>> >>>> Also, I'm certainly open to contributions for Luminus. I moved it to an >>>> org recently and new members would be very welcome. :) >>>> >>>> >>>> On Saturday, May 2, 2015 at 4:43:53 PM UTC-4, g vim wrote: >>>>> >>>>> I recently did some research into web frameworks on Github. Here's >>>>> what >>>>> I found: >>>>> >>>>> >>>>> FRAMEWORK LANG CONTRIBUTORS COMMITS >>>>> >>>>> Luminus Clojure 28 678 >>>>> Caribou Clojure 2 275 >>>>> >>>>> Beego Golang 99 1522 >>>>> >>>>> Phoenix Elixir 124 1949 >>>>> >>>>> Yesod Haskell 130 3722 >>>>> >>>>> Laravel PHP 268 4421 >>>>> >>>>> Play Scala 417 6085 >>>>> >>>>> Symfony PHP 1130 20914 >>>>> >>>>> Rails Ruby 2691 51000 >>>>> >>>>> >>>>> One could conclude from this that the Clojure community isn't that >>>>> interested in web development but the last Clojure survey suggests >>>>> otherwise. Clojure's library composition approach to everything only >>>>> goes so far with large web applications, as Aaron Bedra reminded us in >>>>> March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower >>>>> means less momentum and more bugs. Furthermore, I have a hunch that >>>>> Clojure's poor adoption as indicated by Indeed.com maybe due to this >>>>> immaturity in the web framework sphere. Why is it that Elixir, with a >>>>> much smaller community and lifespan than Clojure's, has managed to put >>>>> 4 >>>>> times as much mindshare into its main web framework when its module >>>>> output, as measured by modulecounts.com, is a tiny fraction of >>>>> Clojure's? >>>>> >>>>> gvim >>>>> >>>>> >>>>> >>>>> >>>>> -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
