Re: [Social-discuss] Which of four projects are we doing?

[Carlo von Loesch]

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.