[buddypress-dev] Portable friends
Justin Ball
justinball at gmail.com
Mon Apr 7 15:23:36 GMT 2008
What about using RSS or Atom to move friend data around. It seems
like we could use that format for all of these:
> - Display the current status of each friend
> - Display the latest post from each friend
> - Show what topics your friends have been posting on
> - Display recently-added photos from friends
> - Compare favourites etc. with friends
If we use a standard format we can also use existing libraries to
parse the data. Other developers will also be able to use similar
libraries both in Wordpress and on other platforms to do the same
thing. I think that to get broadest adoption we need to stick as
close to common, simple formats as possible.
Justin
On Sun, Apr 6, 2008 at 8:37 AM, Chris Taylor - stillbreathing.co.uk
<chris at stillbreathing.co.uk> wrote:
> Hi,
>
> I've been thinking about the data portability issue recently and would
> like some input on the 'friends' aspect. Some of the discussion so far
> shows that some of the functionality required by a social network
> 'friends' feature can be handled well by the existing Wordpress
> blogroll: which can contain a list of URIs which can be tagged with
> XFN. One of the things BuddyPress could do (and also make a wider
> Wordpress plugin) is handle the import/export and synchronisation of
> these lists through OPML. That's relatively straightforward.
>
> However there are other things that a friends application does that a
> blogroll (currently) can't. Off the top of my head here's a few:
>
> - Display the current status of each friend
> - Display the latest post from each friend
> - Show what topics your friends have been posting on
> - Display recently-added photos from friends
> - Compare favourites etc. with friends
>
> I'm sure there are lots more (each of these may need a separate format
> so they can be implemented separately). When the user and their
> friends are in the same system, i.e. the same database, it's pretty
> easy to make all these things happen - it's just a question of SQL
> queries. But if these friends are going to be spread about not just
> around the same site, but also blogs and other SNs then things start
> to get hairy. The amount of data that could need to be transmitted
> every time a user wants to check for their friends updates could be
> prohibitive for site admins wanting this feature.
>
> 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.
>
> 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".
>
> 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.
>
> Any thoughts?
>
> Chris
> _______________________________________________
> buddypress-dev mailing list
> buddypress-dev at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/buddypress-dev
>
More information about the buddypress-dev
mailing list