I would leave the name "camping" for the original gem, and would choose another one for the fork.
But exactly what are those features that you (all) would like to add to camping? - before/after methods of controllers, - something around serving static files and R(), - ??? Actually I think it's not logical that you can build HTML by default using Markaby, but you can't build CSS in the same way. And I hate the trick with __END__ and appended CSS code. It's not good if you "require" your app into a production environment, for example. u. 2012/4/16 Isak Andersson <icepa...@lavabit.com> > ** Like I've kind of said. I don't want the history of camping to > disappear. But I do want to move forward. I'd say create a "classic" branch > and put it in a "camping-classic" gem. And then move on with New extra > bossy beef Camping for real enterprise jungle guns! (?) > > Cheers! > > Isak Andersson > > Jenna Fox <a...@creativepony.com> skrev: >> >> So the 3kb thing is pretty important to you? Anyone else feel the same >> way? :) >> >> — >> Jenna >> >> On Monday, 16 April 2012 at 10:17 PM, Nokan Emiro wrote: >> >> Hi, >> >> As a simple user of Camping I would prefer to have a classic and >> a "modern" one. in one gem or in separate ones, that's not an issue. >> I would like to use the old one without modifications in my apps, and >> if I need extra features, I can uncomment/inser a line like this: >> >> require 'camping' >> require 'camping/session' >> # require >> 'camping_fancy_extra_things_like_before_n_after_controllers_and_static_file_servings_and_tricky_url_mappings_like_sinatras_etc' >> Camping.goes :MyApp >> module MyApp >> ... >> >> But it's just a feature request... >> >> u. >> >> >> 2012/4/15 Isak Andersson <icepa...@lavabit.com> >> >> ** Ah, no I didn't mean maintaining two versions. Just making sure that >> everything in current Camping works as it should (not sure it does, my >> migrations aren't happening) and then freeze it. Call it Camping classic >> and then re-write it to be well designed for extensibility. With readable >> code and all. The names for things in our methods should be more then one >> character lång when we aren't worrying about size anymore. >> >> Cheers! >> >> Isak Andersson >> >> david costa <gurugeek...@gmail.com> skrev: >> >> Hi all :) >> I have been playing with Sinatra a lot lately and perhaps *some* things >> are done easily there (URL mapping, static files) but being a DSL and not a >> framework it is a bit different. For many things camping does the job very >> well and overall I find it a more comprehensive solution than Sinatra. >> >> For the classic/new versions I think the issue would be if the main code >> maintainer (Magnus) should decide if he is willing to do that. Of course >> other people could do that too but it would still be two versions to >> maintain or, if you are freezing camping-classic as it is it should at >> least have a light maintenance that ensures that it would still works fine. >> >> Everyone can fork (e.g. camping-couch is a gem with couch db and no >> active record) the only issue is maintenance and build momentum about it ! >> Regards >> David >> >> >> >> On Sat, Apr 14, 2012 at 4:46 PM, Isak Andersson <icepa...@lavabit.com>wrote: >> >> Right. We could just have a branch called "classic" on github. Leaving >> everything untouched. >> >> And then change the gem name to camping-classic or something. >> >> Maybe we should rewrite it afterwards (kind of). And make it backwards >> compatible with Camping applications. Just make the infrastructure simple >> and minimalistic. And make it easy to extend and configure. I think this >> would be the best thing ever for Camping more or less. >> >> Cheers! >> >> Isak Andersson >> >> Philippe Monnet <r...@monnet-usa.com> skrev: >> >> On one hand everyone is free to fork anything to change radical >> direction. This would allow for the size and some design constraints to be >> eliminated. But on the other hand, at this point in time (since we are the >> new community) shouldn't we free ourselves from the original constraints >> and just ignore the size aspect? I personally think so. It does not mean we >> have to "go crazy" and make it large and complicated (like Rails). >> With the source being on Github, we can just designate the current >> version as the "classic" (super micro version) and document very explicitly >> that from now on we will be free of these constraints and explain how >> people can still get the "classic" version. Since the framework has proven >> extremely stable and resilient, this would not prevent any tinkerer who >> needs the classic version to just do so. >> Although it has been fun to reference the size when talking about >> Camping, keeping it reasonably simple and small is good enough for me. >> >> "... free free set them free ..." >> >> On 4/13/2012 9:55 AM, Isak Andersson wrote: >> >> I agree, I'd like to see the way Camping works to grow in to something >> much more usable. Perhaps a fork is a good idea because the legacy would >> remain and all. But then in the fork we could deal with things that might >> be kind of annoying at times. And grow it with a steady pace. >> >> If we'd fork camping I think we should still stay as minimalistic as >> possible. Only adding the best things. And work on making it easy to extend. >> >> Cheers! >> >> Isak Andersson >> >> Dave Everitt <dever...@innotts.co.uk> <dever...@innotts.co.uk> skrev: >> >> There's a crucial point here... if 3k (the old 4k) is a 'proof of >> concept' and a great exercise in programming skill, it isn't something that >> most users will really worry about. If the 3k limit has to be broken back >> up to 4 or even 5k to get some added/altered/optional functionality that >> would help usability for the rest of us, it's not an issue for me - DaveE >> >> 3kb is great and all, but it seems kind of dishonest if the framework >> isn't even really usable without a bunch of other gems and files and stuff. >> The conflict between 3/4kb and having robust well designed features often >> seems to haunt this project. Maybe time for a forking? I have next to no >> interest in 3kb as a real feature. >> >> >> Get the best selection of online sites here. Click Here to check them >> out! >> >> http://click.lavabit.com/dijea1fjy66jdsnewkjgbtrhtydj4b1pdtfh1jbkrr736gayp7sb/ >> >> >> _______________________________________________ >> Camping-list mailing >> listCamping-list@rubyforge.orghttp://rubyforge.org/mailman/listinfo/camping-list >> >> >> Play Your Favorite Free Games Right On Your Browser - 100% Free! >> >> http://click.lavabit.com/d663gxud89959x7mk3m3o7u8hp6r8h6yfbx1dkxash7qztba1ify/ >> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list@rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> Get the best selection of cell phone sites here. Click Here to check >> them out! >> >> http://click.lavabit.com/6q99xb3hbqi7x1ayckxg8nri1ihmuwngfqcgf1dhq9abaf4d535y/ >> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list@rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> _______________________________________________ >> Camping-list mailing list >> Camping-list@rubyforge.org >> http://rubyforge.org/mailman/listinfo/camping-list >> >> >> Get the best selection of math sites here. Click Here to check them out! >> >> http://click.lavabit.com/qsuiwstet8g8z7t9968n5rcdn8sa77m5tq4cjmkw3e4ps54wqm3b/ >> > > _______________________________________________ > Camping-list mailing list > Camping-list@rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >
_______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
