Thanks!
Or, simply a parameter to ask for them optionally? I don't mind this
method, but it requires two calls to assemble a user timeline.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- The more corrupt the state, the more numerous the laws. -- Tacitus ---------
Lists:
* add list details node (eg. same as GET list_id method) to other
lists methods such as 'GET list statuses', 'GET list members', 'GET
list subscribers' - would allow me to replicate the individual 'list
pages' like on twitter.com without the need to make additional api
calls (not a huge issue with the forthcoming rate limit increase.)
--
Sent from my mobile device
+1
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Time makes more converts than reason. -- Thomas Payne ----------------------
Right, exactly. I would adore this.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- END OF LINE. ---------------------------------------------------------------
What would be the difference between this and home_timeline (
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_timeline
)?
--
Julio Biason <julio....@gmail.com>
Twitter: http://twitter.com/juliobiason
On Dec 18, 2:09 pm, Marcel Molina <mar...@twitter.com> wrote:
We're talking about user_timeline, not friends_timeline (but I wouldn't
mind this idea being applied to other methods, natch).
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- I had amnesia once -- or twice. --------------------------------------------
Thank you, this is badly needed!!!
On Dec 19, 10:21 pm, Cameron Kaiser <spec...@floodgap.com> wrote:
> > >> Or conceivably (though arguably janky) there could be an additional
> > >> parameter you provide for the user timeline that opts you in to having
> > >> retweets appear. e.g. ?include_retweets=true
>
> > > Right, exactly. I would adore this.
>
> > What would be the difference between this and home_timeline (
> >http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_t...
> > )?
>
> We're talking about user_timeline, not friends_timeline (but I wouldn't
> mind this idea being applied to other methods, natch).
>
> --
> ------------------------------------ personal:http://www.cameronkaiser.com/--
> Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com
I had once suggested this feature:
* add retweet_count to every status representation
My issue was by placing retweeted statuses once into the home
timeline, my app was no longer able to keep track of retweets over
time. I think even having the retweet_count still does not change
that. Isn't the issue here (at least that's how the home time line
works) that a retweet is just placed once into the timeline. So the
first time a status is retweeted the retweet count would be 1. After
that, and assuming someone is using the user/home timeline the same
status would not be placed twice at the top level... so an app polling
for new tweets adn potentially tracking retweets would never get an
updated retweet count.
Only if you pull the info about that retweet directly you would get
that count. For many of us, this means wasting a request just for
checking the retweet count... we only have 150 per hour.
The only way I hopefully can keep track of retweets, count them, etc.
is by using the streaming API. I am still waiting for an twitter4j
update which hopefully let's me track retweets properly again.
If there is a better way to keep track of retweets of a status over
time, I'd love to hear it.
Cheers
Sven
?include_duplicate_retweets=true
This would mean that whenever one of my friends retweets a status, I'd
still get a new entry into the home/user time line. It would stop me
from having to listen to the streaming methods to get all retweets
over time. Even better, the retweet_count would provide a lot more
sense to me then. I'd assume the retweet_count reflects all global
retweets of a status. This means my app would both be able to track
how many of my friends retweeted a status compared to all global
retweets (of people I am not or not yet following).
It's christmas, me can haz duplicate_retweets=true?
Thanx
Sven
On Dec 18, 3:38 pm, Marcel Molina <mar...@twitter.com> wrote:
> Or conceivably (though arguably janky) there could be an additional
> parameter you provide for the user timeline that opts you in to having
> retweets appear. e.g. ?include_retweets=true
>
> On Fri, Dec 18, 2009 at 3:08 PM, Cameron Kaiser <spec...@floodgap.com>wrote:
>
>
>
> > > It would be good to be able to get retweets in a user's timeline. If
> > > that is not possible for backwards compatibility reasons, is it
> > > possible to have a function such as retweets_by_user which has similar
> > > semantics to retweets_by_me, except we can specify the user whose
> > > retweets are being retrieved (requiring appropriate authentication for
> > > protected users, of course)?
>
> > Or, simply a parameter to ask for them optionally? I don't mind this
> > method, but it requires two calls to assemble a user timeline.
>
> > --
> > ------------------------------------ personal:
> >http://www.cameronkaiser.com/--
> > Cameron Kaiser * Floodgap Systems *www.floodgap.com*
Yes... please add this to the API.
It would restore the ability to see retweets for non-authenticated
users.