Mentions with since_id is worthless - proposed fix

[Remy Sharp]

Sorry for a slightly gaming subject line, but I've just worked out
that the 'since_id' parameter is worthless in the mentions api call.
It may also be the case in every other API call - but let me explain.

The only time that I can think that you need to use the since_id param
is if you want to start looking at tweets from that point in time
onwards.

The API supports a count param, so technically I may only be
interested in the first tweet since X id:

If the tweet with the ID 1800200012 was posted 15 days ago (and I've
had lot of mentions since) - I would expect to use the following call
to get the mentions after that particular tweet:

http://twitter.com/statuses/mentions.xml?since_id=1800200012&count=1

However, since the API call does all the mentions up to "now" - it
gives me the my latest tweet.

If there was a way to work backwards, i.e. in reverse order then it
would solve this issue in one fell swoop.

Possibly using:

http://twitter.com/statuses/mentions.xml?since_id=1800200012&count=1&sort=desc

This would be really useful for the personal timeline too, since I
could track the first tweet when I got on holiday, and then follow
each tweet since without having to depend on the search API (which is
still limited to 3 weeks of data).

What do you think? Should/could this be made in to feature?

Cheers

--

Remy Sharp

[Sherif]

I agree with you on the reverse order, but slightly disagree on the
since_id statement (yes, you did grab my attention from the subject
line!)

I do find since_id very helpful when using the search API.

Very often I would load tweets for a given search string. As I start
loading these tweets, I grab the first tweet, and make that my last
since_id. Next time my job runs, it resumes from the last since_id and
iterates over the results. I find this a simple and effective method.

It could be improved however using reverse order. Not just for the
reasons you specified, but also for error handling. For example, if
you use my logic above and have the following tweet_id's

1, 2, 3, 4

I start my script, and start loading the tweets. It starts from 4, and
sets the last since_id=4, then loads, 3, 2, and 1. What happens if
after loading 3 there is an API error? (hypothetical) The developer
would then need to manually roll-back their batch if they are using
the since_id method. If this was done in reverse order, it would be
simpler, you would not need to do anything but make the last loaded
tweet the since_id (instead of the first)...

And yes.... didn't that sound confusing?! :-)
Sherif

On May 30, 8:42 pm, Remy Sharp <r...@leftlogic.com> wrote:
> Sorry for a slightly gaming subject line, but I've just worked out
> that the 'since_id' parameter is worthless in the mentions api call.
> It may also be the case in every other API call - but let me explain.
>
> The only time that I can think that you need to use the since_id param
> is if you want to start looking at tweets from that point in time
> onwards.
>
> The API supports a count param, so technically I may only be
> interested in the first tweet since X id:
>
> If the tweet with the ID 1800200012 was posted 15 days ago (and I've
> had lot of mentions since) - I would expect to use the following call
> to get the mentions after that particular tweet:
>
> http://twitter.com/statuses/mentions.xml?since_id=1800200012&count=1
>
> However, since the API call does all the mentions up to "now" - it
> gives me the my latest tweet.
>
> If there was a way to work backwards, i.e. in reverse order then it
> would solve this issue in one fell swoop.
>
> Possibly using:
>

> http://twitter.com/statuses/mentions.xml?since_id=1800200012&count=1&...