Another question occurred to me as I think about this more and start
designing the code that I will use with my site (http://twxlate.com).

The statuses/retweeted_by_me method complements the statuses/
user_timeline method: user_timeline "Returns the 20 most recent
statuses posted from the authenticating user."; retweeted_by_me
"Returns the 20 most recent retweets posted by the authenticating
user.". However, with the user_time method, "It's also possible to
request another user's timeline via the id parameter.". The
retweeted_by_me method does not have this option, and I think it
should. Can this be added?

I think maybe the statuses/retweets_of_me method should also have an
optional id parameter, but I could be wrong about this.

The statuses/retweeted_to_me method also does not have an optional id
parameter, but the absence here is, I think, correct.

Comments expected and welcome.

Jim

On Aug 18, 7:35 pm, "jim.renkel" <james.ren...@gmail.com> wrote:
> Marcel: thank you for the quick response to my questions.
>
> Not surprisingly, your answers have raised a couple of more
> questions. :-)
>
> 1. What happens if I give aretweetid number to the status/show
> method? An error? The retweeted status message is returned along with
> information about all of its retweets? I'm really hoping for the
> second option here, and, if that is not the case currently,  I would
> encourage twitter to make that enhancement. It seems to me to be
> natural to want information on one specificretweet, just as one can
> get specific information on one specific status update.
>
> For the next 2 questions, assume A is following B and C, that B has
> retweeted a status update say two days ago, and C has retweeted the
> same status update yesterday.
>
> 2. In the response to a statuses/home_timeline request for user A,
> will the retweeted status update and all its retweeting information be
> duplicated at the two appropriate places in the timeline, once for B
> and once for C? Or will one or the other be elided?
>
> 3. If the answer to 2, above, is "the retweeted status update is
> duplicated", does the retweeting information reflect the state of the
> twitterverse as it exists at the time the request is made or the state
> at the time theretweetwas created? Specifically, will the retweeting
> information for B'sretweetshow that C has also retweeted it, even
> though C hadn't yet retweeted it when B did?
>
> 4. Assume count=20 is specified on the statuses/home_timeline request.
> Does the retweeted status update and all of its retweets count as just
> 1 of the 20 status updates in the response (i.e., the response could
> have more than 20 elements, potentially way more, but all of the
> retweets of a status update would appear in one "page" of the
> response)? Or does eachretweetcount as 1 of the 20 (i.e., the
> response will have only 20 elements, but the retweets of a single
> status update could be spread across many, potentially very many,
> pages)? I think it would have to be the former, as "Clients may [only]
> request up to 3,200 statuses via the page and count parameters for
> timeline RESTAPImethods." (Quoted from theAPIdocumentation under
> "6) There are pagination limits".), and if it were the latter ya
> couldn't even return all theretweetinformation for a status update
> that was retweeted more than 3200 times (Which DOES happen.).
>
> 5. "statuses/home_timeline" is like "statuses/friends_timeline" but
> with retweets. There is no method that is like "statuses/
> user_timeline" but with retweets. It can be synthesized by merging the
> results of statuses/user_timeline and statuses/retweeted_by_me method
> requests, but only for the authenticating user: the statuses/
> retweeted_by_me method does not take id and user_id parameters as the
> statuses/user_timeline method does. I think there's something missing
> here: if I can see any users status updates, why can't I see their
> retweets?
>
> 6. There are no methods like "statuses/mentions" and "favorites" but
> including retweets (Or do those methods' results now include
> retweets?). I see no way at all of synthesizing these. I think these
> need to be provided for completeness.
>
> 7. Similarly, I'm guessing that "statuses/friends" and "statuses/
> followers" responses don't include retweets (But if a user's last
> update was aretweet, what do they report? The last update that wasn't
> aretweet?). Again, I don't see a way of synthesizing these, and I
> think methods that do include retweets need to be provided for
> completeness.
>
> The reason for wanting the completeness is to avoid user confusion.
> Users will get used to seeing retweets, when they exist, when the home
> timeline is displayed, and assume that if none are displayed, none
> exist. I fear that they will then make that same assumption when
> mentions, favorites, friends, and followers are displayed: no retweets
> displayed, ergo no retweets exist. That may or may not be correct.
>
> 'Nough for now.
>
> Comments expected and welcome.
>
> Answers demanded! "-)
>
> Jim Renkel
>
> On Aug 17, 1:56 pm, Marcel Molina <mar...@twitter.com> wrote:
>
> > Thanks for your questions. Responses inline...
>
> > On Mon, Aug 17, 2009 at 10:31 AM, jim.renkel<james.ren...@gmail.com> wrote:
>
> > > I have both practical and philosophical concerns and questions with
> > > this proposal. Since I'm a little late in commenting on this, some of
> > > these have already been raised. Where I know that is the case, I'll
> > > keep it short, but include it to show my support (or not) of the
> > > issue.
>
> > > This post contains practical issues. A companion post will contain
> > > philosophical issues.
>
> > > 1. When aretweetis created it is assigned an ID number, just like a
> > > status update. Are retweets and status updates numbered from the same
> > > sequence of numbers, or separate ones? I mainly ask out of curiosity,
> > > but there are some implications as shown below.
>
> > Tweets and retweets are currently numbered from the same sequence of 
> > numbers.
>
> > > 2. Is there a limit on the number of times a status update can be
> > > retweeted? Again, curiosity, but with implications.
>
> > No.
>
> > > 3. In the UI, if a status update is shown that has been retweeted, are
> > > all retweeters of the update listed, or, e.g., just ones that I
> > > follow? If all retweeters are listed, what if the status update was
> > > retweeted, say, 1,000 times? 10,000 times? If just retweeters that I
> > > follow are listed, can I somehow see a list of all the retweeters?
>
> > The UI concern of indicating who has retweeted has been addressed,
> > though it isn't displayed in the sample screenshot. It is collapsed
> > into a count of the total number of retweets with a summary after a
> > certain threshold.
>
> > > 4. The response to the status/retweetmethod provides details about
> > > theretweetthat was created. Does it also include details on previous
> > > retweets of the status update?
>
> > No.
>
> > > 5. In the response to the statuses/home_timeline, statuses/
> > > retweeted_by_me, statuses/retweeted_to_me, and statuses/retweets_of_me
> > > methods, how are multiple retweets of the same status update encoded?
> > > I far as I could see, none of the examples addressed this. Is the
> > > status update repeated once perretweet? Or are multiple retweets
> > > listed under one instance of the status update that was retweeted? In
> > > the latter case, the response would presumably look like:
> > >    <?xml version="1.0" encoding="UTF-8"?>
> > >        <statuses>
> > >            <status>
> > >                ...
> > >                <user>
> > >                    ...
> > >                    </user>
> > >                <retweet_details>
> > >                    ... [details of 1stretweet]
> > >                    </retweet_details>
> > >                <retweet_details>
> > >                    ... [details of 2ndretweet]
> > >                    </retweet_details>
> > >                ...
> > >                </status>
> > >            </statuses>
> > > I could be wrong, but I don't think this is valid XML. I think ya need
> > > to have another level of grouping, as in:
> > >    <?xml version="1.0" encoding="UTF-8"?>
> > >        <statuses>
> > >            <status>
> > >                ...
> > >                <user>
> > >                    ...
> > >                    </user>
> > >                <retweets>
> > >                    <retweet_details>
> > >                        ... [details of 1stretweet]
> > >                        </retweet_details>
> > >                    <retweet_details>
> > >                        ... [details of 2ndretweet]
> > >                        </retweet_details>
> > >                    ...
> > >                </retweets>
> > >            </status>
> > >        </statuses>
>
> > "Is the status update repeated once perretweet?" Yes.
>
> > > 6. Each XML retweet_details "section" takes around 100-200 characters
> > > to encode. If a response that includes retweet_details only returns
> > > retweets for those I follow, if I have 20 retweeted status updates
> > > each with, say, 20 retweets, that's 20*20*100=40000 plus characters
> > > required for the response. Even if the response only includes 1
> > > retweeted status update, but it has been retweeted 10,000 times (Not
> > > unheard of! And IMHO it's more likely to happen once this is deployed
> > > and folk start writing "retweebots"), that's 1*10000*100=1000000 plus
> > > characters. I think there's a problem here that needs to be addressed.
>
> > Here you are trading off payload size with number of network calls.
> > Rather than exposing IDs pointing to the author of theretweetand the
> > tweet that is retweeted, we've opted to include the data inline. More
> > pathological scenarios involving retweetbots are mitigated with a
> > combination of measures outside the purview of the platform team.
>
> > > 7. If retweets and status updates are numbered from the same sequence
> > > of IDs, then presumably statuses/destroy can be used to delete a
> > >retweet. If retweets and status updates have separate ID sequences,
> > > then I don't see any way to delete aretweet. I think the ability to
> > > delete aretweetis essential! BTW, I don't see any delete capability
> > > in the proposed UI.
>
> > In the absence of an obvious use case for including theretweet'sid,
> > we were omitting it. Deleting theretweetvia theAPIis a very
> > reasonable use case. Thanks. We'll add a 'retweet_id' to the
> > retweet_details section.
>
> > > 8. If a protected user retweets a status update of a non-protected
> > > user, will the protected user always / sometimes / never be listed as
> > > a retweeter of the public user's status update?
>
> > > 9. Conversely, if a
>
> ...
>
> read more »

Reply via email to