Had a feeling that would be the response. How long will the current
polling search API be alive (and supported)?

The demultiplexing of the status messages prevents a simple migration
path - as a matter of fact it requires a completely new architecture
for our collection from Twitter. As (or more) importantly it will
likely force changes that will impact downstream ETL/metadata
generation processes.

I do, however, understand the need (in terms of efficiency) to keep
concurrent connections optimized.

Can one be relatively assured that future iterations of the Search API
will have some degree of backwards compatibility?

regards,

Brian Roy

On Nov 18, 4:11 pm, John Kalucki <jkalu...@gmail.com> wrote:
> There's no need to open a connection per user. You should demultiplex
> the messages from a single connection or from a very small number of
> connections. 
> Seehttp://groups.google.com/group/twitter-development-talk/browse_frm/th...
>
> -John Kaluckihttp://twitter.com/jkalucki
> Services, Twitter Inc.
>
> On Nov 18, 2:46 pm, briantroy <brian.cosin...@gmail.com> wrote:
>
>
>
> > I have a question about the streaming API.
>
> > I am currently whitelisted for the standard search API on several IP
> > addresses. I'd like to begin moving to the streaming API (at least to
> > test) but am blocked by the "one connection per account" limit.
>
> > Is there a way to be whitelisted (by IP or credentials) to have
> > multiple connections? Is the assumed methodology that I would create a
> > single "stream" for 100's or 1000's of clients and somehow figure out
> > on my side which track term goes with which client?
>
> > Any help would be appreciated.
>
> > regards,
>
> > Brian Roy
> > justSignal.com

Reply via email to