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 scrapped together sourcecode and kickstarted a DIY revival. Why handed this project off to this community long before he left the scene. The lineage is unbroken, and it is our responsibility to bring it forward (or not). If Why has any opinion on any of this he's fully welcome to let us know, but so far as I know, he has shown no opinion to date.
Anyway, I agree with your priorities, but I remain in favour of a soft limit. No point building another Sinatra. We already have one of those. — Jenna On Wednesday, 25 April 2012 at 11:26 PM, Anthony Durity wrote: > 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 is. A hard > upper limit prevents bloat. > > Regarding improving/adding stuff to Camping in light that technology has > moved on, is moving on. > > The whole reason Rack came into existence was to centralise duplicated web > framework code as a middle layer. This should in theory make the web > frameworks more simple, more robust. It means that if your web framework uses > Rack you get all its functionality at a cost of learning a new interface. > > With this in mind web frameworks should still innovate and then any agreed on > commonalities should migrate to Rack. Thus the question of implementing > EventStream/WebSocket/long- > polling-support is a question of architecting Camping to support these > technologies. If it is done well in Camping then perhaps we'll be copied by > other frameworks and, as I said, perhaps over time these features will > migrate into Rack if it makes sense. > > The first two things that I added to my Camping installation were: > 1) the ability to serve static files in dev mode > 2) before/after handlers > > I think also that client side the tech is HTML/JS/CSS. Thus it actually does > make sense from a symettrical and consistent point of view that if you have > the inbuilt ability to spit out HTML you should have the ability to spit out > JS and also CSS. Also I think it does make sense to parameterize CSS as well > as JS. I see no reason why not. > > In short, I'd like Camping to track new developments in tech, I'd like it to > gain obvious missing features, I'd like it to keep more or less the same > architectural structure and code size limit _if_ possible. If not, > considering that _why is no longer around I do not think that it would be > appropriate to use the name he assigned his hack for a project that did not > follow his ideals. Choose another name, can't be that hard, can it? > > Regards, > Anthony > > > On Wed, Apr 18, 2012 at 5:12 PM, Magnus Holm <judo...@gmail.com > (mailto:judo...@gmail.com)> wrote: > > On Wed, Apr 18, 2012 at 17:49, Jenna Fox <a...@creativepony.com > > (mailto:a...@creativepony.com)> 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 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? > > > > And more importantly: How can I do I/O inside the callback without > > blocking the server. In this case, many servers (e.g. Thin) would only > > be able to serve one client at a time because you're using IO#gets > > which blocks the whole process (you can't use Thread.new in Thin). > > > > Also, env['async.callback'] is not a standard; different servers may > > support it differently (e.g. Thin only allows you to use I/O that uses > > EventMachine). > > > > > 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. > > > > Fibers and continuations doesn't solve the problem. Fibers/callcc can > > make callback-based code look like blocking (without actually being > > blocking), but it can't turn blocking into non-blocking. As long as > > the server assumes that #call will block until it gets a response, > > it's not going to handle other clients until the #call returns. > > _______________________________________________ > > 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 (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
