Thanks John,
That makes sense to me, I thought this might be the case.

~redders.

2010/1/12 John Kalucki <j...@twitter.com>

> Historical queries are always going to be the strong point of the Search
> API. You should perform initial queries against Search to collect the
> history, then transition to Streaming for the duration of the query demand.
>
> The Streaming API offers a few minutes of backlog to allow connections to
> cycle, request the last few minutes of statuses, and avoid missing data. The
> status count is a proxy for seconds that you were disconnected. If you know
> the approximate rate of statuses created per second, and how many seconds
> you were off, you can adjust the backlog more finely. This is easiest to see
> at the Firehose level, otherwise you have to overrequest and deduplicate.
>
> If you are using a filtered resource at an elevated access level, you
> specify how many statuses to examine, not the number of results. The idea is
> the same- to paper over the time between connections, not specify a result
> set size.
>
> We only offer the count parameter on the firehose and higher access levels
> of follow. It's probably too expensive to run for track and counter to
> the philosophy of the sample feeds. (It probably should work on the Retweet
> and Links stream, but it doesn't.) If there's popular demand, we can look
> into filling these gaps.
>
> -John Kalucki
> http://twitter.com/jkalucki
> Services, Twitter Inc.
>
> On Tue, Jan 12, 2010 at 8:11 AM, Edward Hinchliffe <
> redders6...@googlemail.com> wrote:
>
>> Thanks John, that's been helpful. It looks like storing tweets is fine...
>>
>> On related note, the documentation suggests that tweets using the "search
>> API" (REST), are time limited to ~1.5 weeks.
>>
>> I have read that developers are now encouraged to use the streaming API. I
>> see that it's possible to get historic tweets from the streaming API, but
>> reading the documentation quoted below, I get the impression that this is
>> limited to 150,000 tweets *before* they have been filtered. So if I searched
>> for a term that has not been tweeted in the last 150,000 tweets, I'll get no
>> historic results? Or have I interpreted that completely wrong? :)
>> ~~~
>> count
>>
>> Indicates the number of previous statuses to consider for delivery before
>> transitioning to live stream delivery. On unfiltered streams, all considered
>> statuses are delivered, so the number requested is the number returned. On
>> filtered streams, the number requested is the number of statuses that are
>> applied to the filter predicate, and not the number of statuses returned.
>> *Values:* -150,000 to 150,000. This range is subject to change on short
>> notice. Positive values transition seamlessly to the live stream. Negative
>> values terminate when the historical stream has finished, useful for
>> debugging.
>>
>> ~~~
>>
>> Thanks in advance,
>>
>> ~redders.
>>
>> 2010/1/12 John Kalucki <j...@twitter.com>
>>
>> The following also apply:
>>> http://twitter.com/tos
>>> http://twitter.com/apirules
>>> http://help.twitter.com/forums/26257/entries/18311
>>>
>>>
>>>
>>> On Tue, Jan 12, 2010 at 5:56 AM, redders <redders6...@googlemail.com>wrote:
>>>
>>>> Hi All,
>>>>
>>>> Just wanted to ask  a quick question regarding historic tweets. Is
>>>> there anything in the twitter T&Cs to say that search results can't be
>>>> stored?
>>>>
>>>> I ask because the API only returns results from the last week (?) or
>>>> so... what if I want to use data from previous searches I've
>>>> conducted.
>>>>
>>>> Also, is there any other T&C doc other than this page:
>>>> http://apiwiki.twitter.com/Terms-of-Service
>>>>
>>>> Cheers,
>>>> ~redders.
>>>>
>>>
>>>
>>
>

Reply via email to