To Push? or To Pull?
Dec 27th, 2007 by Aswath
In a user-centric social network (aka distributed social network) two friends who would like to share data will nominally use different servers. So we have to decide how the data will be shared between the four entities – the two servers and the two clients. In effect we need to decide who will pull the data from whom.
Email is an early example where such a decision was made. In email, the sender’s client pushes the dat to its server, which pushes it to the receiver’s server from which the receiver pulls it finally. In my opinion the fact that the sender’s server pushes the data to the receiver’s server has been problematic. To protect its potentially limited storage, the receiver’s server may place arbitrary limit on the size of the data. It would have been preferable for the receiver to pull the data from the sender’s server. But it was not feasible because there was no way for that server to authenticate the receiver.
In more recent times, Instant Messaging services share Presence information of its users among designated “buddies”. Almost all of the IM services have adopted the policy of pushing the Presence information to the clients. As the number of buddies a user has increases, the Presence server needs to scale to handle the traffic. Still they were manageable because, except for the case of limited peering instances, the presence information is centrally located. But in our case, the servers are distributed. So we need to reconsider how to distribute presence information.
These and some additional considerations prompted us to classify the data into three categories and use pull/push method as appropriate:
- Information like “Availability status” are temporal and changing dynamically, but continuously available. Also buddies may be interested in being notified when there is a change is the value. For such data, our plan is for the user to push the data to the sender’s server and allow the buddy to pull the data after authentication using OpenID. Additionally if a buddy is interested in notification, then the buddy can register with the sender’s server. When such an event takes place, the sender’s server will send the notification to the receiver’s server. That server can send a notification (via email, SMS or a third mechanism) or the buddy can pull it from the receiver’s server.
- Information like Calendar appointment are sporadically generated, may be modified and of limited interest even among the buddies. Also, buddies would like to generate such data but need to be approved by the user. For such data, our plan is for the user to push the data to the sender’s server and allow the buddy pull the data after authentication using OpenID. In the case where the buddy is generating the data on behalf of the user, then the buddy will push the data to the sender’s server, which will send a notification (via email, SMS or a third mechanism) or the user can pull it from the user’s server.
- Information like Notes, files and photos are bulk items are generated sporadically but persist for a long period of time. In such cases, the user will push the data to the user’s server, which will send a short notification (via email, SMS or a third mechanism) or the user can pull it from the user’s server.
[…] when that “free” service suddenly goes away or turns pay-to-play. The best idea is to store it on your own server and push it out to those whom want to connect. Seems like the best idea to me, what say you? Related Posts:Dipping […]