social-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Henry Litwhiler
Subject: Re: [Social-discuss] Which of four projects are we doing?
Date: Sat, 27 Mar 2010 12:40:20 -0400
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

On 3/27/10 11:50 AM, Matt Lee wrote:
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.

  
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.

  
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.

  
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.

  
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.

  
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 to happen.

--
Henry L.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]