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
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 si
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 Sina
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
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'
requi
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'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 co
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
Jenn
On Mon, Apr 16, 2012 at 5:40 PM, Dave Everitt wrote:
> 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 `re
Awww - the commented version is well worth reading through:
https://github.com/camping/camping/blob/master/lib/camping-unabridged.rb
DaveE
The source of Camping is something that I don't want to see again. :)
___
Camping-list mailing list
Camping-l
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'
W dniu 16 kwietnia 2012 20:50 użytkownik Nokan Emiro
napisał:
> 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.
You never need to insert any variables into your CSS code. (If you do,
you're doing it wrong.)
-- Matma R
On Sun, Apr 15, 2012 at 01:59, david costa wrote:
> 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
2012/4/16 Bartosz Dziewoński
> W dniu 16 kwietnia 2012 20:50 użytkownik Nokan Emiro
> napisał:
> > 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.
>
> You never need to insert any variables into your CSS code. (If
On Mon, Apr 16, 2012 at 09:20:18PM +0200, Bartosz Dziewoński wrote:
> W dniu 16 kwietnia 2012 20:50 użytkownik Nokan Emiro
> napisał:
> > 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.
>
> You never need to insert a
>
>
> For now I'm feeling like a pretty bad "maintainer". I'm not using
> Camping enough to see where things need to be fixed, I'm crappy at
> actually shipping stuff, and I'm not sure if I believe that Camping is
> a correct starting point for a new framework.
>
>
Like so many times before, I have
On Mon, Apr 16, 2012 at 10:14:57PM +0200, Paul van Tilburg wrote:
> On Mon, Apr 16, 2012 at 09:20:18PM +0200, Bartosz Dziewoński wrote:
> > W dniu 16 kwietnia 2012 20:50 użytkownik Nokan Emiro
> > napisał:
> > > Actually I think it's not logical that you can build HTML by default using
> > > Marka
On Mon, Apr 16, 2012 at 22:14, Nokan Emiro wrote:
> 2012/4/16 Bartosz Dziewoński
>>
>> W dniu 16 kwietnia 2012 20:50 użytkownik Nokan Emiro
>> napisał:
>> > 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.
>>
>
Shit! If you told me about it a few hours ago, I wouldn't bother myself
writing a RobotsTxt Controller...
__END__
> @@ /style.css
> * { margin: 0; padding: 0 }
>
> And Camping will serve it for you. See also:
> https://github.com/camping/camping/blob/master/test/app_file.rb
>
>
___
>
>
> For now I'm feeling like a pretty bad "maintainer". I'm not using
> Camping enough to see where things need to be fixed, I'm crappy at
> actually shipping stuff, and I'm not sure if I believe that Camping is
> a correct starting point for a new framework
Hey Magnus! I think that you are a g
To be honest I don't care if we leave the 4k stuff behind or not. I just want
Camping to be easy to extend and customize. Don't get me wrong, Camping is
crazy customizable. The fact that you can set it up to be a huge
application with the rackup file in an extremely cool way is definitely
s
If you want to use something like SASS for CSS, there are gems for
that (or use LESS), but I'd never expect such functionality to be
built into in Camping - that's one of the things I *like* about it: a
small functional default set that works, with options for other ways
left to me. BTW the
+1 to all that David Costa wrote in response. Magnus *has and does*
kept things solid and on track in a way that suits Camping. We're
never going to go head-to-head in the framework competition stakes
(bit late for that anyway, with frameworks swerving all over client-
side dev).
As for en
Isak,
may be you should use the official release for the screencast no ? If is a
screencast about something not yet released what is the use of it...
On Tue, Apr 17, 2012 at 12:23 PM, Isak Andersson wrote:
> To be honest I don't care if we leave the 4k stuff behind or not. I just
> want Camping t
I thought about that, but I want to stay up to date with things like Mab and
all that. There are small differences. But I guess I could omit the use of
anything that differs. But still, we want the information to be fresh, no?
Cheers!
Isak Andersson
david costa skrev:
Isak,
may be you shoul
Agreed, Magnus does an amazing job with Camping! More than anyone else has done
anyway.
Cheers!
Isak Andersson
Dave Everitt skrev:
+1 to all that David Costa wrote in response. Magnus *has and does* kept things
solid and on track in a way that suits Camping. We're never going to go
head-to-
Well Sqlite works fine with the current camping so I don't see any reason
to use something not yet released for the screencasts.
so in short use the official camping-omnibus for the screencasts. I
checked your issue on github but I don't think is the fault of the new
version but that's not the poi
On Mon, Apr 16, 2012 at 22:27, Nokan Emiro wrote:
>>
>> For now I'm feeling like a pretty bad "maintainer". I'm not using
>> Camping enough to see where things need to be fixed, I'm crappy at
>> actually shipping stuff, and I'm not sure if I believe that Camping is
>> a correct starting point for
Yeah I was going to suggest that we do a screencasts going over New features.
Let's go with that instead!
Cheers!
Isak Andersson
david costa skrev:
Well Sqlite works fine with the current camping so I don't see any reason to
use something not yet released for the screencasts.
so in short u
Those are all great points - the eventstream support is a particular sticking
point to me. It feels like a standard which aught to be easily implemented -
even through rack! but I've yet to see any web frameworks where eventstream
doesn't seem like a total hack - except perhaps for Node.JS where
Thought I'd weigh in for what it's worth,
My naive first impression of Camping basically took no notice of the whole
3/4k thing. I appreciate that it's a cool programming feat, and I love the
attitude that lead to it, but at the time my focus was on trying to figure
out what all these hidden insta
Daniel - that's a great reply and echoes much of my own experience
(although my Camping is much more on the tinkering side). The point
about Camping being an educational tool is a good one, which I've even
tried to apply to students (unsuccessfully - but that's my problem),
and it would be
On Wed, Apr 18, 2012 at 15:07, Daniel Bryan wrote:
> Thought I'd weigh in for what it's worth,
Thanks, I find it very interesting.
> My naive first impression of Camping basically took no notice of the whole
> 3/4k thing. I appreciate that it's a cool programming feat, and I love the
> attitude
# Sorry for ranting a little
all very interesting
# even the unabridged code is far from readable
# I think my attraction as a novice to Camping was for its clarity
these two things are inconsistent? but this brings it around:
# I'm being incoherent
# quickly I ended up using models in my apps t
I think the trouble with streaming over the rack interface is that it's
confusing. I'm fairly good at ruby, but I'm not entirely sure how it would even
work. I guess I need to run my app in a threaded web server, running every
request in it's own thread? Then inside the each iterator in the resp
Not to forget Perl (who would have thought that?) which currently
has the best web framework I've ever seen: http://mojolicio.us/
I would have thought it - my sometimes co-developer opened my eyes to
Titanium:
http://mark.stosberg.com/blog/2008/12/titanium-a-new-release-and-more.html
and no
On Wed, Apr 18, 2012 at 17:49, Jenna Fox wrote:
> I think the trouble with streaming over the rack interface is that it's
> confusing. I'm fairly good at ruby, but I'm not entirely sure how it would
> even work. I guess I need to run my app in a threaded web server, running
> every request in it's
Hi,
The reason I got into camping was because it was written by _why , because
liked the way _why looked at things and approached things. Camping contains
the spirit of _why , if you alter it too much it ceases to be Camping. Part
of the attraction is the tiny size, the 3k/4k limit or whatever it
I don't think Why felt all that strongly about Camping. Anyway he's busy doing
other stuff now and pretty explicitly left the project in Magnus’ hands. Why
may have started this whole mess, but it is Magnus who is the beloved leader.
This isn't like many of Why's abandoned projects where people
39 matches
Mail list logo
