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> wrote:
> On Wed, Apr 18, 2012 at 17:49, Jenna Fox <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
> http://rubyforge.org/mailman/listinfo/camping-list
>
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
