framework size, forking etc.
gurugeekphp at gmail.com
Sat Apr 14 23:59:34 UTC 2012
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 !
On Sat, Apr 14, 2012 at 4:46 PM, Isak Andersson <IcePapih at 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.
> Isak Andersson
> Philippe Monnet <ruby at 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.
>> Isak Andersson
>> Dave Everitt <deveritt at innotts.co.uk> <deveritt at 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
>> Camping-list mailing listCamping-list at rubyforge.orghttp://rubyforge.org/mailman/listinfo/camping-list
>> Play Your Favorite Free Games Right On Your Browser - 100% Free!
> Camping-list mailing list
> Camping-list at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Camping-list