If adding the other states (pending, blocked, etc) then I would agree with the "redundancy" by having all attributes present in both "source" and "target" objects. These relationships are not necessarily symmetric, so it makes sense to have them in each object since they would not necessarily be redundant.
-Chad On Tue, Jun 9, 2009 at 8: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 >
