[buddypress-dev] Portable friends

Joseph Scott joseph at randomnetworks.com
Mon Apr 7 14:52:12 GMT 2008


On Apr 6, 2008, at 8:37 AM, Chris Taylor - stillbreathing.co.uk wrote:

> So my thoughts are that a users friends list *shouldn't* go to their
> friends to see if data has changed. Instead when someone, for example,
> updates their status that new text should be sent to anyone in their
> friends list. Here's an example.
>
> Bob and Dave are friends. Dave updates his status text, and the change
> gets posted (using RPC?) to all of Dave's friends, including Bob. The
> next time Bob logs in he sees Dave's latest status.


When I gave my examples on this I specifically didn't mention a  
transport mechanism, but I was thinking XML-RPC :-)


> This minimises the amount of remote polling because friends' sites are
> only called when there is has been an update made - not to check if
> there *has* been an update made. It can also be made secure, because a
> user could set their status updates to "everyone", but their photo
> gallery updates only to "family".


I very much prefer active notification to polling.


> Lastly it puts the status of the friendship under the data senders
> control. Another example:
>
> Jack has said he is Jill's friend. But Jill isn't Jack's friend, ever
> since that part at Bob's house where he got a bit frisky by the punch
> bowl. Jack might want to know when Jill updates her status message so
> he can harass her, but he isn't going to get those notifications
> automatically because he isn't in Jill's friends list. And because
> Jack isn't in Jill's friends list she can say whether she wants to see
> notifications from him or not, by leaving the "View updates from
> people who say they are your friend (but you haven't said you are
> theirs)?" box unchecked.


This goes back to the discussion on fine grained control, which I  
think everyone has agreed is a good thing.

--
Joseph Scott
joseph at randomnetworks.com
http://joseph.randomnetworks.com/





More information about the buddypress-dev mailing list