I'm not too bothered about 3k. But I think what Nokan's saying is that
he'd like Camping to remain functioning as it is so he can continue to
run his apps as they're set up now, but that extra features could be
added with an optional `require 'camping/new_extra_stuff`... - Nokan,
is this correct? Although I've no practical idea about how this might
best be achieved - DaveE
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 <[email protected]>
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 <[email protected]> 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 <[email protected]
> 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 <[email protected]> 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 <[email protected]> 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 list
[email protected]
http://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
[email protected]
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
[email protected]
http://rubyforge.org/mailman/listinfo/camping-list
_______________________________________________
Camping-list mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/camping-list
_______________________________________________
Camping-list mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/camping-list
_______________________________________________
Camping-list mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/camping-list
