[twitter-dev] Re: Purposed method: friendships/show
I agree with Chad: explicitly stating the source and target in the
attribute name makes it much clearer. It also has a side benefit of
bringing the information you need most (for a UI) to the top of the
results hierarchy.
-ch
On Jun 9, 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 }
}
}
On Tue, Jun 9, 2009 at 10:41 AM, Chad Etzel jazzyc...@gmail.com wrote:
Hi Marcel,
Welcome to Twitter, btw (if I'm allowed to say that).
One unambiguous way might be:
{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
}
}
This also eliminates redundant data.
Btw,http://twitter.com/@noradiodoesn't quite work as a link :)
-Chad
On Tue, Jun 9, 2009 at 1:33 PM, Marcel Molina mar...@twitter.com wrote:
Hey Chad, thanks for your feedback.
Thought experiment: Put aside the currently proposed response body for
the moment. How would you unambiguously express the following/followed
by relationship?
Marcel Molina
Twitter API Team
http://twitter.com/@noradio
On Jun 9, 10:23 am, Chad Etzel jazzyc...@gmail.com wrote:
Thanks for adding the extra verbiage.
However, I'm still not clear how to decipher the exact relationship
given the data. In the example, is Bob following Jack? ...or is Jack
following Bob?
-Chad
On Tue, Jun 9, 2009 at 1:12 PM, Doug Williams d...@twitter.com wrote:
Thanks, Chad. I've augmented the usage notes section to explain the
rationale behind the denormalized and redundant data.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel jazzyc...@gmail.com
wrote:
Taking a look at the json return example:
{relationship: {
source: {
id: 123,
screen_name: bob,
following: true,
followed_by: false,
notifications: false },
target: {
id: 456,
screen_name: jack,
following: false,
followed_by: true,
notifications: null }
}
}
In the source object (i.e. for bob), following is true. Does
this mean that Bob is following Jack, or vice-versa?
Knowing that, the other 3 following/followed_by value meanings can be
properly inferred. Some clarification on the page would help.
-Chad
On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams d...@twitter.com
wrote:
That makes things difficult. Permissions are now public.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel jazzyc...@gmail.com
wrote:
qoute
Access Denied
You don't have permission to look at Twitter REST API Method:
friendships
show.
/quote
:)
-Chad
On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams d...@twitter.com
wrote:
We discussed the need to deprecate the following and
notifications
elements [1] a few weeks back. We have begun work on the
friendships/show
method as mentioned in the notice. The method is slightly out of
our
conventional design, so we are soliciting opinions on its
fitness for
general use-cases. Please peruse the purposed method's
documentation
[2]
and
let us know what you think.
1.
http://groups.google.com/group/twitter-development-talk/browse_frm/th...
2.
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
Thanks,
Doug
--
Marcel Molina
Twitter API Teamhttp://twitter.com/noradio
[twitter-dev] Re: Purposed method: friendships/show
In thinking this through a little more and how this would fit into my
applications, I have another suggestion to propose.
Currently, if an application requests the followers of user B, on
behalf of user A (i.e., the request is authenticated with user A's
credentials), it gets back the list of B's followers, their latest
status update, plus (partial) indications of the relationship between
each of B's followers and user A. The application can use that
information to enable user A sending DMs to the follower if that
follower of B is also following A, to enable user A to request to
follow the follower of B if they are not already doing so, or remove
the follow if they are, etc., etc., etc.
If that relationship information is not included in the response to
the request for the followers of B, but must be requested separately,
as is being proposed, the real problem that I see is that, as
proposed, if I get back 50 followers of B in the response to the
request for B's followers, I now have to make 50 relationship requests
to get the same information that was included before, albeit
inaccurately. This has big implications for latency, server overhead,
rate limits, etc., etc., etc.
What I propose is that a request for relationship information can
include a list of targets, and the response would include the
relationship information for each target in the list vis-a-vis the
source user.
Of course, now ya run into complications concerning the validity of
target users: I would hope that ya would not reject the whole request
just because one or more target users were invalid, but that ya would
selectively indicate the invalidity, and return the requested
information for valid targets.
I don't know what the impact of adopting this proposal would be on the
API server side, but the impact of NOT adopting this suggestion is
potentially huge on both the client and server.
And, on a different tangent, is there any impact in this on the
favorited indication that appears as part of a status update's
information in some API responses? Will we be expected to have to make
separate API requests to get that information?
Again, comments expected, welcome, and appreciated.
Jim Renkel
On Jun 9, 7:51 pm, Chad Etzel jazzyc...@gmail.com wrote:
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 Molinamar...@twitter.com
wrote:
Thanks for the suggestion Chad.
What do others think of
{relationship: {
source: {
id: 123,
[twitter-dev] Re: Purposed method: friendships/show
qoute Access Denied You don't have permission to look at Twitter REST API Method: friendships show. /quote :) -Chad On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams d...@twitter.com wrote: We discussed the need to deprecate the following and notifications elements [1] a few weeks back. We have begun work on the friendships/show method as mentioned in the notice. The method is slightly out of our conventional design, so we are soliciting opinions on its fitness for general use-cases. Please peruse the purposed method's documentation [2] and let us know what you think. 1. http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e 2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show Thanks, Doug
[twitter-dev] Re: Purposed method: friendships/show
That makes things difficult. Permissions are now public. Thanks, Doug On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel jazzyc...@gmail.com wrote: qoute Access Denied You don't have permission to look at Twitter REST API Method: friendships show. /quote :) -Chad On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams d...@twitter.com wrote: We discussed the need to deprecate the following and notifications elements [1] a few weeks back. We have begun work on the friendships/show method as mentioned in the notice. The method is slightly out of our conventional design, so we are soliciting opinions on its fitness for general use-cases. Please peruse the purposed method's documentation [2] and let us know what you think. 1. http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e 2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show Thanks, Doug
[twitter-dev] Re: Purposed method: friendships/show
Taking a look at the json return example:
{relationship: {
source: {
id: 123,
screen_name: bob,
following: true,
followed_by: false,
notifications: false },
target: {
id: 456,
screen_name: jack,
following: false,
followed_by: true,
notifications: null }
}
}
In the source object (i.e. for bob), following is true. Does
this mean that Bob is following Jack, or vice-versa?
Knowing that, the other 3 following/followed_by value meanings can be
properly inferred. Some clarification on the page would help.
-Chad
On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams d...@twitter.com wrote:
That makes things difficult. Permissions are now public.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel jazzyc...@gmail.com wrote:
qoute
Access Denied
You don't have permission to look at Twitter REST API Method: friendships
show.
/quote
:)
-Chad
On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams d...@twitter.com wrote:
We discussed the need to deprecate the following and notifications
elements [1] a few weeks back. We have begun work on the
friendships/show
method as mentioned in the notice. The method is slightly out of our
conventional design, so we are soliciting opinions on its fitness for
general use-cases. Please peruse the purposed method's documentation [2]
and
let us know what you think.
1. http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e
2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
Thanks,
Doug
[twitter-dev] Re: Purposed method: friendships/show
Thanks, Chad. I've augmented the usage notes section to explain the
rationale behind the denormalized and redundant data.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel jazzyc...@gmail.com wrote:
Taking a look at the json return example:
{relationship: {
source: {
id: 123,
screen_name: bob,
following: true,
followed_by: false,
notifications: false },
target: {
id: 456,
screen_name: jack,
following: false,
followed_by: true,
notifications: null }
}
}
In the source object (i.e. for bob), following is true. Does
this mean that Bob is following Jack, or vice-versa?
Knowing that, the other 3 following/followed_by value meanings can be
properly inferred. Some clarification on the page would help.
-Chad
On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams d...@twitter.com wrote:
That makes things difficult. Permissions are now public.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel jazzyc...@gmail.com wrote:
qoute
Access Denied
You don't have permission to look at Twitter REST API Method:
friendships
show.
/quote
:)
-Chad
On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams d...@twitter.com
wrote:
We discussed the need to deprecate the following and notifications
elements [1] a few weeks back. We have begun work on the
friendships/show
method as mentioned in the notice. The method is slightly out of our
conventional design, so we are soliciting opinions on its fitness for
general use-cases. Please peruse the purposed method's documentation
[2]
and
let us know what you think.
1.
http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e
2.
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
Thanks,
Doug
[twitter-dev] Re: Purposed method: friendships/show
Thanks for adding the extra verbiage.
However, I'm still not clear how to decipher the exact relationship
given the data. In the example, is Bob following Jack? ...or is Jack
following Bob?
-Chad
On Tue, Jun 9, 2009 at 1:12 PM, Doug Williams d...@twitter.com wrote:
Thanks, Chad. I've augmented the usage notes section to explain the
rationale behind the denormalized and redundant data.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel jazzyc...@gmail.com wrote:
Taking a look at the json return example:
{relationship: {
source: {
id: 123,
screen_name: bob,
following: true,
followed_by: false,
notifications: false },
target: {
id: 456,
screen_name: jack,
following: false,
followed_by: true,
notifications: null }
}
}
In the source object (i.e. for bob), following is true. Does
this mean that Bob is following Jack, or vice-versa?
Knowing that, the other 3 following/followed_by value meanings can be
properly inferred. Some clarification on the page would help.
-Chad
On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams d...@twitter.com wrote:
That makes things difficult. Permissions are now public.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel jazzyc...@gmail.com wrote:
qoute
Access Denied
You don't have permission to look at Twitter REST API Method:
friendships
show.
/quote
:)
-Chad
On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams d...@twitter.com
wrote:
We discussed the need to deprecate the following and
notifications
elements [1] a few weeks back. We have begun work on the
friendships/show
method as mentioned in the notice. The method is slightly out of our
conventional design, so we are soliciting opinions on its fitness for
general use-cases. Please peruse the purposed method's documentation
[2]
and
let us know what you think.
1. http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e
2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
Thanks,
Doug
[twitter-dev] Re: Purposed method: friendships/show
Hey Chad, thanks for your feedback.
Thought experiment: Put aside the currently proposed response body for
the moment. How would you unambiguously express the following/followed
by relationship?
Marcel Molina
Twitter API Team
http://twitter.com/@noradio
On Jun 9, 10:23 am, Chad Etzel jazzyc...@gmail.com wrote:
Thanks for adding the extra verbiage.
However, I'm still not clear how to decipher the exact relationship
given the data. In the example, is Bob following Jack? ...or is Jack
following Bob?
-Chad
On Tue, Jun 9, 2009 at 1:12 PM, Doug Williams d...@twitter.com wrote:
Thanks, Chad. I've augmented the usage notes section to explain the
rationale behind the denormalized and redundant data.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel jazzyc...@gmail.com wrote:
Taking a look at the json return example:
{relationship: {
source: {
id: 123,
screen_name: bob,
following: true,
followed_by: false,
notifications: false },
target: {
id: 456,
screen_name: jack,
following: false,
followed_by: true,
notifications: null }
}
}
In the source object (i.e. for bob), following is true. Does
this mean that Bob is following Jack, or vice-versa?
Knowing that, the other 3 following/followed_by value meanings can be
properly inferred. Some clarification on the page would help.
-Chad
On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams d...@twitter.com wrote:
That makes things difficult. Permissions are now public.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel jazzyc...@gmail.com wrote:
qoute
Access Denied
You don't have permission to look at Twitter REST API Method:
friendships
show.
/quote
:)
-Chad
On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams d...@twitter.com
wrote:
We discussed the need to deprecate the following and
notifications
elements [1] a few weeks back. We have begun work on the
friendships/show
method as mentioned in the notice. The method is slightly out of our
conventional design, so we are soliciting opinions on its fitness for
general use-cases. Please peruse the purposed method's documentation
[2]
and
let us know what you think.
1. http://groups.google.com/group/twitter-development-talk/browse_frm/th...
2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
Thanks,
Doug
[twitter-dev] Re: Purposed method: friendships/show
Hi Marcel,
Welcome to Twitter, btw (if I'm allowed to say that).
One unambiguous way might be:
{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
}
}
This also eliminates redundant data.
Btw, http://twitter.com/@noradio doesn't quite work as a link :)
-Chad
On Tue, Jun 9, 2009 at 1:33 PM, Marcel Molina mar...@twitter.com wrote:
Hey Chad, thanks for your feedback.
Thought experiment: Put aside the currently proposed response body for
the moment. How would you unambiguously express the following/followed
by relationship?
Marcel Molina
Twitter API Team
http://twitter.com/@noradio
On Jun 9, 10:23 am, Chad Etzel jazzyc...@gmail.com wrote:
Thanks for adding the extra verbiage.
However, I'm still not clear how to decipher the exact relationship
given the data. In the example, is Bob following Jack? ...or is Jack
following Bob?
-Chad
On Tue, Jun 9, 2009 at 1:12 PM, Doug Williams d...@twitter.com wrote:
Thanks, Chad. I've augmented the usage notes section to explain the
rationale behind the denormalized and redundant data.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel jazzyc...@gmail.com wrote:
Taking a look at the json return example:
{relationship: {
source: {
id: 123,
screen_name: bob,
following: true,
followed_by: false,
notifications: false },
target: {
id: 456,
screen_name: jack,
following: false,
followed_by: true,
notifications: null }
}
}
In the source object (i.e. for bob), following is true. Does
this mean that Bob is following Jack, or vice-versa?
Knowing that, the other 3 following/followed_by value meanings can be
properly inferred. Some clarification on the page would help.
-Chad
On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams d...@twitter.com wrote:
That makes things difficult. Permissions are now public.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel jazzyc...@gmail.com wrote:
qoute
Access Denied
You don't have permission to look at Twitter REST API Method:
friendships
show.
/quote
:)
-Chad
On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams d...@twitter.com
wrote:
We discussed the need to deprecate the following and
notifications
elements [1] a few weeks back. We have begun work on the
friendships/show
method as mentioned in the notice. The method is slightly out of our
conventional design, so we are soliciting opinions on its fitness for
general use-cases. Please peruse the purposed method's documentation
[2]
and
let us know what you think.
1. http://groups.google.com/group/twitter-development-talk/browse_frm/th...
2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
Thanks,
Doug
[twitter-dev] Re: Purposed method: friendships/show
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 }
}
}
On Tue, Jun 9, 2009 at 10:41 AM, Chad Etzel jazzyc...@gmail.com wrote:
Hi Marcel,
Welcome to Twitter, btw (if I'm allowed to say that).
One unambiguous way might be:
{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
}
}
This also eliminates redundant data.
Btw, http://twitter.com/@noradio doesn't quite work as a link :)
-Chad
On Tue, Jun 9, 2009 at 1:33 PM, Marcel Molina mar...@twitter.com wrote:
Hey Chad, thanks for your feedback.
Thought experiment: Put aside the currently proposed response body for
the moment. How would you unambiguously express the following/followed
by relationship?
Marcel Molina
Twitter API Team
http://twitter.com/@noradio
On Jun 9, 10:23 am, Chad Etzel jazzyc...@gmail.com wrote:
Thanks for adding the extra verbiage.
However, I'm still not clear how to decipher the exact relationship
given the data. In the example, is Bob following Jack? ...or is Jack
following Bob?
-Chad
On Tue, Jun 9, 2009 at 1:12 PM, Doug Williams d...@twitter.com wrote:
Thanks, Chad. I've augmented the usage notes section to explain the
rationale behind the denormalized and redundant data.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel jazzyc...@gmail.com
wrote:
Taking a look at the json return example:
{relationship: {
source: {
id: 123,
screen_name: bob,
following: true,
followed_by: false,
notifications: false },
target: {
id: 456,
screen_name: jack,
following: false,
followed_by: true,
notifications: null }
}
}
In the source object (i.e. for bob), following is true. Does
this mean that Bob is following Jack, or vice-versa?
Knowing that, the other 3 following/followed_by value meanings can be
properly inferred. Some clarification on the page would help.
-Chad
On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams d...@twitter.com
wrote:
That makes things difficult. Permissions are now public.
Thanks,
Doug
On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel jazzyc...@gmail.com
wrote:
qoute
Access Denied
You don't have permission to look at Twitter REST API Method:
friendships
show.
/quote
:)
-Chad
On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams d...@twitter.com
wrote:
We discussed the need to deprecate the following and
notifications
elements [1] a few weeks back. We have begun work on the
friendships/show
method as mentioned in the notice. The method is slightly out of
our
conventional design, so we are soliciting opinions on its
fitness for
general use-cases. Please peruse the purposed method's
documentation
[2]
and
let us know what you think.
1.
http://groups.google.com/group/twitter-development-talk/browse_frm/th...
2.
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
Thanks,
Doug
--
Marcel Molina
Twitter API Team
http://twitter.com/noradio
[twitter-dev] Re: Purposed method: friendships/show
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 Molinamar...@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 }
}
}
[twitter-dev] Re: Purposed method: friendships/show
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 Molinamar...@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 }
}
}
[twitter-dev] Re: Purposed method: friendships/show
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 Molinamar...@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
[twitter-dev] Re: Purposed method: friendships/show
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 Molinamar...@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
[twitter-dev] Re: Purposed method: friendships/show
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 Molinamar...@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
