Nice. Now I get it. I agree. Comet isn't going to get very far if it requires you to completely change your design. Event driven is an interesting design concept but there's just too many existing apps and too much existing know-how out there for building web apps the way we do now. (Which is indeed slightly event driven but not to the extent Comet wants it to be.)
Couple of questions: The separate server uses threads or non-blocking I/O? I guess with Ruby's current threading model you could scale to a couple of thousand connections but threading is only going to take you about that far. (Having native threads is going to limit it much earlier.) What about temporary disconnects from the client? (HTTP infrastructure usually doesn't like long-lived connections.) Is there a queuing system in place so the client will receive those messages when he reconnects? Doesn't have to be rocket science but I do think this is a problem that needs to be solved. You guys using this in Campfire? Planning to? Cheers, Jon On 4/23/06, David Heinemeier Hansson <[EMAIL PROTECTED]> wrote: > > I could have sworn DHH said he ran a Twisted server daemon > > specifically to handle the long-lived Armageddon threads. > > Armageddon uses a separate socket server, so you don't have any > problems with each connection taking up a FCGI process. That would not > be very scalable. Which is the core objection I have against Comet: It > requires you to complete rearchitect your application. > > Armageddon works with what already is. > > > Client A --opens socket to--> Socket Server > Client B --makes xhr call that client A should see--> FCGI --sends > message to--> Socket Server > > So the socket server works like a bus. The great thing about this is > that the socket server is stupid simple. It's just a registry, which > allows you to send text to a socket identified by an id. > > And since we already have this wonderful system known as RJS, we can > push RJS updates from client B to client A reusing the same templates > as client B used to update himself. > > Very dry, very low-overhead, very easy to use and understand. > -- > David Heinemeier Hansson > http://www.loudthinking.com -- Broadcasting Brain > http://www.basecamphq.com -- Online project management > http://www.backpackit.com -- Personal information manager > http://www.rubyonrails.com -- Web-application framework > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
