On 3/27/10 11:50 AM, Matt Lee wrote:
I have to agree with Carlo. PHP is all well and good for creating a
graphical, browser-based frontend, but we are going to need a strong
backend application in C or Python.
On 03/27/2010 09:08 AM, Carlo von Loesch wrote:
No Matt, I have to disagree with this impossible design goal.
If we stay in PHP playground land without a proper backend protocol
we will only be able to make yet another web-based social engine
without a scalable real-time link to the rest of the world.
Please don't be disparaging to PHP.
Yeah, the round-robin approach should work. It is going to be a very
small amount of data being sent - just enough so that every user knows
that something has been posted.
A social network in a Facebook style generates events a go-go.
Each time a user adds a comment somewhere, each time a user likes
something, writes an update, joins a group or adds a friend.
Every time a notice needs to be distributed to all peers.
This is a one-to-many operation that hasn't got a ghost of a chance
of scaling if implemented as a round-robin series of HTTP calls.
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.
Even on the cheapest and nastiest of web hosting.
We don't want users buying web hosting to host their GNU Social
installs. If we do that, it becomes (effectively) a service,
that they have to pay for to use. That simply should not have
Is there some magic trick I am not familiar with that allows us to do
real protocols on persistent TCP connections on so-called "commodity
webhosting" or should we rather create such a profoundly important
technology that will influence "commodity webhosting" in such a way
that it will become common to support gnu social?
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.
And we should do that in the lower common denominator possible -- PHP
with a RDBMS.
Only then will the average computer user be able to quickly set up or
obtain/purchase GNU social service from a willing provider.