Matt Lee typeth: | Please don't be disparaging to PHP. Sorry, don't mean to. What I mean is this typical habit of commodity php hosting of not supporting daemon mode, thus no listening sockets, no stack of ready-to-use open TCP links. Is that still the state of things? Can PHP receive packets by UDP?
| How many friends does the average Facebook user have? Even it's its | 10,000 -- I can't see why if I publish a status update, 10,000 other | servers couldn't access a URI, similar to an RSS feed, and get the info. You mean you intend to poll the URIs of 10,000 friends all the time while you are online? Or are we at least talking about push? | We should focus on making something simple, which publishes its own | updates in a way that other servers request them in a timely manner, | rather than the individual server pushing them out. Something simple will not beat Facebook. If that's what you want, I'm out. My aim is to beat Facebook and provide P2P features on top. Something simple will not even be able to deliver the real-time feel (try 'live feed') of Facebook for 10'000 people on 100 servers with 100 friends each. Let alone real world numbers. | And we should do that in the lower common denominator possible -- PHP | with a RDBMS. That's not a common denominator, it's a solution that runs on popular hardware and a design decision against several other useful ways to do this. Would it be possible to design this software in such a way that instead of doing HTTP-based interactions it can pass messaging operations to a router daemon running on the same host? Then we get to have the high overhead version for php hosting and a low overhead version for real servers. Not sure if that would be enough to scale, though, since the entire network is affected by servers running in overhead mode.
