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 response object it just sleeps until it's got more data, using some sort of global message queue object to organise messaging between all the different threads? What if I'm deploying to passenger? what about fastcgi? Does that mean one ruby process per stream? Right now I have a few thins running with a ngynix proxy. Will the proxy be okay with sending in multiple concurrent requests in to the thins or will it need to have a process per user?
It's well and truly away from being the simple rack thing everyone liked. It only gets worse when you start wanting websockets - which don't fit the rack model at all (and rightly so! but they still need to be supported) In the end what I really want is to be able to return a Rack::Stream.new as the response, which will do the each magic and deal with the web server in some way where it's the server's responsibility to make sure it works - none of my concern, and where I can keep around a reference to that Stream object and send it messages. It's actually a pretty simple problem to solve, except for getting the different ruby servers to implement one common standard on how to deal with ruby apps which have lots of long running connections open. Maybe it could be made to work somewhat okay, but I cannot imagine in my head having ten thousand sleeping threads open waiting for something to stream out is going to be very performant. There's also the Fibers and Continuations stuff which is probably about as close as we can get to a good work around for a completely artificial problem created by the rack interface. — Jenna On Thursday, 19 April 2012 at 12:59 AM, cdr wrote: > # 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 that were just representations > of the filesystem, or of some other API, or of documents in CouchDB > yep, to me a 'model' at request time is always based on inside some CSV or > JSON file, an Email, an IRC log, something curl piped to a file in a script > run by cron > > the notion that you'll be writing new ruby Classes for each class of resource > in th datamodel, and new "routes", and "migrations" to prime DB tables seems > fundamentally crazy to me, and with rails' mindtrain it was copied on > sinatra,camping,merb,ramaze > > # I've mostly moved onto working in Python > i tired of ruby around 2007 after writing the webserver i actually wanted, > rather than the "framework" i didnt want. it is baroque for the possibility > of a runtime type-error failure to even exist. with type-inference, your > Haskell or OCaml code is not more verbose than Ruby. i still maintain my > webserver since it works fine but i'd never start a new project in ruby at > this point > > # their community actually brags about it, and makes a point of how much > easier your life could be if you use it > the Rails community did this quite a bit too. all the alphabloggers like > Ezra/Tom/court8nay and countless HN/Reddit mobs. i think it ties into human > psychology of self-apprised status somehow, but it is just silliness, like > obsessing about getting into a "VIP Room" at a club > > > 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. > > > > > Rack is really simple, in goes a Hash of request environment, out goes a > status-number, response environment + body. essentially thats what HTTP is. > after making handlers for ebb, flow, mongrel, it was nice to delete all that > code and just write a rack handler - they were all so similar anyways > > as for streaming, i was able to trivially implement 'tail -f' using rack [0] > am interested in hearing what your thoughts on how Rack should change > > [0] http://gitorious.org/element/element/blobs/master/ruby/W/tail.rb > _______________________________________________ > Camping-list mailing list > Camping-list@rubyforge.org (mailto: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
