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.
