On Mar 11, 9:29 am, Matt Sanford <
m...@twitter.com> wrote:
> Hi,
>
> That query of 'ors=sad=all' looks a little goofy, I would suggest
> 'q=sad+OR+all' if you're looking for both. I just tried a few
> different things and it seems like this is an issue with combining
> max_id and since_id. The max_id parameter was added to make sure the
> page parameter works correctly. I've oddly never tested using it to
> circumvent the pagination limit. I'll take a look at it but please
> open a Google Code issue (
http://code.google.com/p/twitter-api/issues/entry
> ) so I don't forget.
>
> A quick aside about the pagination limit: It's not there to make
> it hard on people or somehow hide our data, it's there to make
> searches faster. When you go back in time we have to read data from
> disk and replace recent data in memory with that older data. The
> pagination limit is there to prevent too much of our memory space
> being taken up by old data that a very small percentage of requests
> need.
>
> Thanks;
> — Matt
>
> On Mar 11, 2009, at 09:11 AM, Ronnie wrote:
>
>
>
> > Hey Matt,
>
> > Nish is right, I don't see a warning message that the max_id that
> > max_id is adjusted unless since_id is not specified
>
> > Here's a sample json request: