Wouldn't we get a lot of irrelevant users that way? Is it possible to
stream both on user id's an keywords, or is it one or the other?

Regarding the count, would it be possible to access the API every 5
minutes, say, using a negative count parameter?  Or better just to use
the streaming feature as it's intended?  The former seems easier to
develop since we can just point a cron script at it and not worry
about having a long-lived process that keeps the connection open.


On Sep 9, 2:23 am, John Kalucki <jkalu...@gmail.com> wrote:
> At first glance, it seems that you should track on the keywords you
> care about with the Streaming API, and then sort by user on your
> client end.
> The count parameter allows clients to mask data loss at reconnection-
> time. It won't be sufficient for your purposes as the look back is
> only a few tens of minutes at most.
> -John Kaluckihttp://twitter.com/jkalucki
> Services, Twitter Inc.
> On Sep 8, 10:17 pm, LeeS <lse...@gmail.com> wrote:
> > For a new project we'll need to retrieve the text of recent statuses
> > for a large group of specific users (several thousand to start),
> > matching a smaller list of keyword strings.   Both the users and
> > keywords will grow over time but the keyword set will probably remain
> > at least an order of magnitude smaller than the set of users and grow
> > more slowly  Real time is not important and the statuses can be a few
> > hours old.  Is using the 'shadow' method of the Streaming API with a
> > negative 'count' parameter the best way to do this with a minimum load
> > on the API?  If so, what's the best way to obtain the access needed?
> > It looks like the initial base of users is going to outstrip the
> > 'filter' method's limitation, and 'filter' doesn't allow for the use
> > of 'count' in the default role.
> > Thanks
> > --Lee Semel
> > Recent Twitter projects:  http://muckrack.com -http://venturemaven.com
> > -http://twittorati.com-http://shortyawards.com-http://shortyawards.com...

Reply via email to