Though, it should be mentioned, w/r/t/ to pending follow requests and blocks, you'd only get a value for those attributes for authenticated requests where the source user is authenticated.
On Tue, Jun 9, 2009 at 5:22 PM, Marcel Molina <mar...@twitter.com> wrote: > Good point about pending requests for protected accounts and the > opportunity to get parity. > My inclination is rather than overloading following and followed_by that we > potentially introduce a 'pending' attribute that is either true or empty. > Similarly we could add a 'blocked'/'blocked_by'. > > These additional attributes sway me toward going with the > representation that (redundantly) specifies the values of each attribute with > the source and target sections as encoding this information in > 'source_has_a_pending_request_for_target' and > 'target_has_a_pending_request_for_source', etc start to get somewhat unwieldy. > > > On Tue, Jun 9, 2009 at 4:29 PM, jim.renkel <james.ren...@gmail.com> wrote: > >> >> It seems from the examples, but not explicitly stated anywhere, that >> the values of the following and followed_by items are booleans, >> implying that a user either is or is not following another user. >> >> While at first blush that seems true, I think in reality the situation >> is a little more complicated, especially if you consider protected >> users. >> >> I would propose that these items be enumerations, with the following >> values and meanings: >> - "yes": user A, say, is following user B; >> - "no": user A is not following user B, has not requested the >> relationship, and is not blocked from doing so; >> - "pending": user A has requested to follow (protected) user B, but B >> has not yet accepted, rejected, or blocked the request; and >> - "blocked": user A requested to follow (protected) user B, but B >> blocked the request. >> >> What I'm looking for here is parity, if you will, between the data and >> facilities that are available to the twitter.com web site and to API >> users. This is one place where there was not parity, and we have the >> opportunity to now get it. >> >> Comments expected, welcome, and appreciated. >> >> Jim Renkel >> >> On Jun 9, 1:13 pm, Damon Clinkscales <sca...@pobox.com> wrote: >> > If you're going to redefine the way that follow information is >> > returned, I believe that it should include the effect of "protected" >> > accounts on both sides of the follow equation. >> > >> > Thanks, >> > -damon >> > --http://twitter.com/damon >> > >> > On Tue, Jun 9, 2009 at 10:52 AM, Marcel Molina<mar...@twitter.com> >> wrote: >> > > Thanks for the suggestion Chad. >> > > What do others think of >> > > {"relationship": { >> > > "source": { >> > > "id": 123, >> > > "screen_name": "bob", >> > > "notifications": false }, >> > >> > > "target": { >> > > "id": 456, >> > > "screen_name": "jack", >> > > "notifications": null }, >> > >> > > "source_follows_target": true, >> > > "source_followed_by_target": false >> > > } >> > > } >> > > versus >> > >> > > {"relationship": { >> > >> > > "source": { >> > >> > > "id": 123, >> > >> > > "screen_name": "bob", >> > >> > > "following": true, >> > >> > > "followed_by": false, >> > >> > > "notifications_enabled": false }, >> > >> > > "target": { >> > >> > > "id": 456, >> > >> > > "screen_name": "jack", >> > >> > > "following": false, >> > >> > > "followed_by": true, >> > >> > > "notifications_enabled": null } >> > >> > > } >> > >> > > } >> > > > > -- > Marcel Molina > Twitter API Team > http://twitter.com/noradio > -- Marcel Molina Twitter API Team http://twitter.com/noradio
