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 instance variables you have in a controller are (the documentation was only of sporadic use), thinking I might just dive into the source to check it out, and obviously being confronted by the fact that even the unabridged code is far from readable (as it wasn't intended to be).
I discovered Camping when I was very new to Ruby, and relatively new to programming in general. Everyone here obviously knows the strengths and reputation of Ruby - and projects like Camping - as a learning language. I've mostly moved onto working in Python, but I think there's a strong chance that my understanding of the architecture of web applications, and HTTP, and my motivation to understand web development at several different layers, would have been different if Camping didn't imply a certain kind of thinking that coloured my behaviour. So why not build on this? There's all sorts of amazing projects all over the web at the moment for making programming accessible to people who are very young, or who have literacy that's poorer than most programmers, or who live in the third world, or who just come from subcultures / cliques where usually you wouldn't do this kind of thing. That's cool, but as soon as these people learn some stuff they want to *do something*, and they want to do it either with mobile or the web. They google around and they find out about, like, what? Rails? Django? What a way to turn people off. One of the reasons I floundered with Camping after a while is that it was really hard to figure out where to, you know, put a lot of my code. Helpers? I guess. This is a pretty typical problem in web frameworks, obviously - where do you put domain-specific logic? Where do you store all your application logic? How lightweight should your controllers be? Do you want fat models? I think ActiveRecord is the elephant in the room here - very quickly I ended up using models in my apps that were just representations of the filesystem, or of some other API, or of documents in CouchDB, or whatever. That was cool, and Camping made that relatively easy, but the fact is I'm not an API designer. I'm not a library writer. Any ad-hoc decision I make about how I might model my data, as an amateurish programmer, is going to be disastrous, but ActiveRecord just couldn't do what I wanted to do without more work than it was worth. So maybe if there was some kind of Camping fork, or a new Camping-inspired framework, or whatever, it could try to encapsulate not just this solid core focused on using class methods as HTTP verbs, but also some kind of pattern. What's the next thing someone needs to know after they're good with Camping? How to write their library code. How to manage the dependencies (ugh). How to deploy it (it took me *forever* to even figure out that I needed something called a 'rackup' file - I eventually found a Heroku guide for Camping, and even then I couldn't get it to work until I stole some code from some project of Magnus' or Jenna's). I'm being incoherent, but in general I think my attraction as a novice to Camping was for it clarity - not even necessarily its simplicity. Why not bring that clarity to the rest of the web development process that surrounds it? People keep talking about Sinatra. Personally - as a completely subjective, essentially arbitrary position - I don't like Sinatra. Whatever you think of it, I think it's possible to point out that we don't need to just look inside the Ruby environment. Why not look at other places where interesting things are happening? Node's "Express" framework, for instance, bears a lot of similarity to Sinatra and Camping; the "Connect" middleware framework that it uses is similar to Rack in many ways. The difference is that their community actually brags about it, and makes a point of how much easier your life could be if you use it for lots of stuff. It looks like there was similar excitement about Rack back in the day, but it doesn't come across that way so much. Maybe just because of the shadow of Rails hanging over everything. Sorry for ranting a little - I keep reading this thread on the way to work and wanting to comment but not having time. In summary - I'm greatful for what Camping provided me as a learning environment, but I think it could go a lot further in supporting the growth of developers who used it, and helping them to do stuff 'correctly' outside of their controllers. It's obvious that sockets and so on excite a lot of young programmers - especially as so many of them have JavaScript as their first language now, but I can't imagine how you'd support something like that properly in something like Camping without building it on top of an event-driven framework. On Wed, Apr 18, 2012 at 10:35 AM, Jenna Fox <a...@creativepony.com> wrote: > 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 the http server class is so low level anything seems equally > easy. I'm not yet convinced WebSocket is useful for very much - it's not > well supported in http servers and reverse http proxies, and it's > full-duplex nature seems unnecessary when ajax is good enough for > responding in most situations. On the other hand, websockets doesn't even > pretend to be anything like a http request aside from setup negotiation, so > there's no implication that a web framework designed for serving pages > should really have anything to do with websocket - much of the websocket > standards specify outputting strings which look like http, but not really > parsing http headers properly or anything. > > I'd love to see some inventive solutions to long polling and event stream. > Rack does seem to be increasingly a source of pain. The guardians of the > rack spec haven't done a good job keeping up with new tech. > > All your other points, I totally agree. Especially regexp routes. I feel > like the camping feature for generating routes from controller names is not > as good as just having a friendly route language. > > One thing I never liked about rails was having routes in a separate file > somewhere, then just some controllers named whatever files. I wonder if the > controller routes couldn't also be the controller's filenames? I guess some > operating systems wouldn't much like filenames with forward slashes in them > though (windows..) > > — > Jenna > > On Wednesday, 18 April 2012 at 6:15 AM, Magnus Holm wrote: > > On Mon, Apr 16, 2012 at 22:27, Nokan Emiro <uzleep...@gmail.com> 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 a new framework. > > > Like so many times before, I have a few silly questions again: > > > There's no silly questions; just puzzled people who don't dare to ask :-) > > - Why do you think so that Camping isn't a good starting point? > > > I like centralized routing (config/routes.rb vs having routes in the > controllers). It's also easier to combine a Sinatra-style-framework > with centralized routing: just allow routing to a block, and `get "/" > do … end` is as natural as `routes.get "/", :to => "home#index"`. > > I prefer Sinatra-style routes over regexps. > > Camping's module magic is just plain bad style. Inheritance is easier > to work with. > > Mapping one URL to one class is a little too verbose for me; I end up > with tons of classes and it's hard to see which classes that actually > work on the same type of data. For controller classes, Rails-style is > more pragmatic. > > It's just 4k; that's hardly any starting point at all :-) > > - What is the problem with Camping in your opinion? > > > There's not a "problem" with Camping. It's an elegant piece of code; > it solves HTTP in a surprisingly "correct" way, although it's not > always so pragmatic/practical. > > - What does a good framework provide for you? > > ...and the most stupid one: > > - Why are you talking about a "new framework"? Why don't we > rewrite Sinatra, Ramaze or whatever over Camping? They have > an interface that's used by others... > > > I just feel like the whole Ruby framework community stagnated a few > years after we got Rack. The moment Rack became properly implemented > everywhere it lacked any kind of > EventStream/WebSocket/long-polling-support. Everything since then has > been hacked on top. > > Rails provides ActiveRecord for database access, but more and more > stuff these days are using HTTP. I believe that a true *web* framework > should provide a HTTP client/user-agent too. Net::HTTP doesn't cut it > (no persistant connection support in stdlib; rather > verbose/inconsistent and no cookie-jar). There are other libraries, > but these have their own conventions and limitations. > _______________________________________________ > 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 >
_______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
