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 <[email protected] > (mailto:[email protected])> 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 > [email protected] (mailto:[email protected]) > http://rubyforge.org/mailman/listinfo/camping-list > >
_______________________________________________ Camping-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/camping-list
