[twitter-dev] Re: Streaming API -- /follow /birddog and /shadow also match in_reply_to field.
For this issue, and all filtering-driven issues, they'll always be
back-to-back. For other causes of overdelivery, duplicates can be
scattered pretty far apart. Overdelivery is usually triggered by
lifecycle events -- servers restarting, your client reconnecting, that
sort of thing. This type of overdelivery is rare, but it can happen.
-John
On Jun 10, 10:09 am, Chad Etzel wrote:
> Cool, thanks.
>
> I have noticed that the duplicates have always (thus far) come in
> back-to-back, so I've just started checking the tweet id against the
> last received tweet id to see if they match. Do you know if that
> should always be the case (until the fix), or if I have just been
> getting lucky so far?
>
> -Chad
>
> On Wed, Jun 10, 2009 at 1:04 PM, John Kalucki wrote:
>
> > This is a known defect. Quick catch! The fix is easy enough and
> > required for future features.
>
> > Streaming API clients need to de-duplicate for a whole host of other
> > reasons, especially those who use the count parameter. The service
> > errs on the side of overdelivery.
>
> > -John
> > Service, Twitter Inc.
>
> > On Jun 9, 9:00 pm, Chad Etzel wrote:
> >> Makes sense.
>
> >> One thing I'm noticing that now this feature is live:
>
> >> If userA and userB are both in my follow id list, and then if userA
> >> makes an explicit reply to userB, I get userA's update twice. Just
> >> something to be aware of for everyone.
>
> >> This "duplicate update" also happens if you have the same user id
> >> listed twice (or more) in the follow id list. I found this out by
> >> merging two follow lists which overlapped. 'sort' and 'uniq' became
> >> my friends soon thereafter.
>
> >> -Chad
>
> >> On Tue, Jun 9, 2009 at 11:24 PM, John Kalucki wrote:
>
> >> > Unlikely.
>
> >> > In general, we treat a status as immutable, but removable.
> >> > Hosebird doesn't re-write statuses.
> >> > Clients can determine this by themselves.
> >> > Too many other things to do!
>
> >> > -John
>
> >> > On Jun 9, 8:10 pm, Chad Etzel wrote:
> >> >> Neato!
>
> >> >> Would it be possible to add some sort of attribute to the status
> >> >> object which indicates when this is the case? (i.e. this update is
> >> >> being sent to you, but the user id of the sender is not explicitly in
> >> >> the follow id list?)
>
> >> >> Would be handy, perhaps.
> >> >> -Chad
>
> >> >> On Tue, Jun 9, 2009 at 10:46 PM, John Kalucki
> >> >> wrote:
>
> >> >> > The follow by userID resources, /follow, /birddog and /shadow, stream
> >> >> > all public statuses filtered by a list of userIDs. In addition to
> >> >> > updates created by users in the list, explicit replies now also match
> >> >> > and are streamed to consumers.
>
> >> >> > Mentions, statuses that contain a given screen name ("Hello @user!"),
> >> >> > but aren't explicit replies, are not matched.
>
> >> >> > -John Kalucki
> >> >> > Services, Twitter Inc.
[twitter-dev] Re: Streaming API -- /follow /birddog and /shadow also match in_reply_to field.
Cool, thanks.
I have noticed that the duplicates have always (thus far) come in
back-to-back, so I've just started checking the tweet id against the
last received tweet id to see if they match. Do you know if that
should always be the case (until the fix), or if I have just been
getting lucky so far?
-Chad
On Wed, Jun 10, 2009 at 1:04 PM, John Kalucki wrote:
>
> This is a known defect. Quick catch! The fix is easy enough and
> required for future features.
>
> Streaming API clients need to de-duplicate for a whole host of other
> reasons, especially those who use the count parameter. The service
> errs on the side of overdelivery.
>
> -John
> Service, Twitter Inc.
>
>
>
> On Jun 9, 9:00 pm, Chad Etzel wrote:
>> Makes sense.
>>
>> One thing I'm noticing that now this feature is live:
>>
>> If userA and userB are both in my follow id list, and then if userA
>> makes an explicit reply to userB, I get userA's update twice. Just
>> something to be aware of for everyone.
>>
>> This "duplicate update" also happens if you have the same user id
>> listed twice (or more) in the follow id list. I found this out by
>> merging two follow lists which overlapped. 'sort' and 'uniq' became
>> my friends soon thereafter.
>>
>> -Chad
>>
>> On Tue, Jun 9, 2009 at 11:24 PM, John Kalucki wrote:
>>
>> > Unlikely.
>>
>> > In general, we treat a status as immutable, but removable.
>> > Hosebird doesn't re-write statuses.
>> > Clients can determine this by themselves.
>> > Too many other things to do!
>>
>> > -John
>>
>> > On Jun 9, 8:10 pm, Chad Etzel wrote:
>> >> Neato!
>>
>> >> Would it be possible to add some sort of attribute to the status
>> >> object which indicates when this is the case? (i.e. this update is
>> >> being sent to you, but the user id of the sender is not explicitly in
>> >> the follow id list?)
>>
>> >> Would be handy, perhaps.
>> >> -Chad
>>
>> >> On Tue, Jun 9, 2009 at 10:46 PM, John Kalucki wrote:
>>
>> >> > The follow by userID resources, /follow, /birddog and /shadow, stream
>> >> > all public statuses filtered by a list of userIDs. In addition to
>> >> > updates created by users in the list, explicit replies now also match
>> >> > and are streamed to consumers.
>>
>> >> > Mentions, statuses that contain a given screen name ("Hello @user!"),
>> >> > but aren't explicit replies, are not matched.
>>
>> >> > -John Kalucki
>> >> > Services, Twitter Inc.
[twitter-dev] Re: Streaming API -- /follow /birddog and /shadow also match in_reply_to field.
This is a known defect. Quick catch! The fix is easy enough and
required for future features.
Streaming API clients need to de-duplicate for a whole host of other
reasons, especially those who use the count parameter. The service
errs on the side of overdelivery.
-John
Service, Twitter Inc.
On Jun 9, 9:00 pm, Chad Etzel wrote:
> Makes sense.
>
> One thing I'm noticing that now this feature is live:
>
> If userA and userB are both in my follow id list, and then if userA
> makes an explicit reply to userB, I get userA's update twice. Just
> something to be aware of for everyone.
>
> This "duplicate update" also happens if you have the same user id
> listed twice (or more) in the follow id list. I found this out by
> merging two follow lists which overlapped. 'sort' and 'uniq' became
> my friends soon thereafter.
>
> -Chad
>
> On Tue, Jun 9, 2009 at 11:24 PM, John Kalucki wrote:
>
> > Unlikely.
>
> > In general, we treat a status as immutable, but removable.
> > Hosebird doesn't re-write statuses.
> > Clients can determine this by themselves.
> > Too many other things to do!
>
> > -John
>
> > On Jun 9, 8:10 pm, Chad Etzel wrote:
> >> Neato!
>
> >> Would it be possible to add some sort of attribute to the status
> >> object which indicates when this is the case? (i.e. this update is
> >> being sent to you, but the user id of the sender is not explicitly in
> >> the follow id list?)
>
> >> Would be handy, perhaps.
> >> -Chad
>
> >> On Tue, Jun 9, 2009 at 10:46 PM, John Kalucki wrote:
>
> >> > The follow by userID resources, /follow, /birddog and /shadow, stream
> >> > all public statuses filtered by a list of userIDs. In addition to
> >> > updates created by users in the list, explicit replies now also match
> >> > and are streamed to consumers.
>
> >> > Mentions, statuses that contain a given screen name ("Hello @user!"),
> >> > but aren't explicit replies, are not matched.
>
> >> > -John Kalucki
> >> > Services, Twitter Inc.
[twitter-dev] Re: Streaming API -- /follow /birddog and /shadow also match in_reply_to field.
Makes sense.
One thing I'm noticing that now this feature is live:
If userA and userB are both in my follow id list, and then if userA
makes an explicit reply to userB, I get userA's update twice. Just
something to be aware of for everyone.
This "duplicate update" also happens if you have the same user id
listed twice (or more) in the follow id list. I found this out by
merging two follow lists which overlapped. 'sort' and 'uniq' became
my friends soon thereafter.
-Chad
On Tue, Jun 9, 2009 at 11:24 PM, John Kalucki wrote:
>
> Unlikely.
>
> In general, we treat a status as immutable, but removable.
> Hosebird doesn't re-write statuses.
> Clients can determine this by themselves.
> Too many other things to do!
>
> -John
>
>
> On Jun 9, 8:10 pm, Chad Etzel wrote:
>> Neato!
>>
>> Would it be possible to add some sort of attribute to the status
>> object which indicates when this is the case? (i.e. this update is
>> being sent to you, but the user id of the sender is not explicitly in
>> the follow id list?)
>>
>> Would be handy, perhaps.
>> -Chad
>>
>> On Tue, Jun 9, 2009 at 10:46 PM, John Kalucki wrote:
>>
>> > The follow by userID resources, /follow, /birddog and /shadow, stream
>> > all public statuses filtered by a list of userIDs. In addition to
>> > updates created by users in the list, explicit replies now also match
>> > and are streamed to consumers.
>>
>> > Mentions, statuses that contain a given screen name ("Hello @user!"),
>> > but aren't explicit replies, are not matched.
>>
>> > -John Kalucki
>> > Services, Twitter Inc.
[twitter-dev] Re: Streaming API -- /follow /birddog and /shadow also match in_reply_to field.
Unlikely.
In general, we treat a status as immutable, but removable.
Hosebird doesn't re-write statuses.
Clients can determine this by themselves.
Too many other things to do!
-John
On Jun 9, 8:10 pm, Chad Etzel wrote:
> Neato!
>
> Would it be possible to add some sort of attribute to the status
> object which indicates when this is the case? (i.e. this update is
> being sent to you, but the user id of the sender is not explicitly in
> the follow id list?)
>
> Would be handy, perhaps.
> -Chad
>
> On Tue, Jun 9, 2009 at 10:46 PM, John Kalucki wrote:
>
> > The follow by userID resources, /follow, /birddog and /shadow, stream
> > all public statuses filtered by a list of userIDs. In addition to
> > updates created by users in the list, explicit replies now also match
> > and are streamed to consumers.
>
> > Mentions, statuses that contain a given screen name ("Hello @user!"),
> > but aren't explicit replies, are not matched.
>
> > -John Kalucki
> > Services, Twitter Inc.
[twitter-dev] Re: Streaming API -- /follow /birddog and /shadow also match in_reply_to field.
Neato!
Would it be possible to add some sort of attribute to the status
object which indicates when this is the case? (i.e. this update is
being sent to you, but the user id of the sender is not explicitly in
the follow id list?)
Would be handy, perhaps.
-Chad
On Tue, Jun 9, 2009 at 10:46 PM, John Kalucki wrote:
>
> The follow by userID resources, /follow, /birddog and /shadow, stream
> all public statuses filtered by a list of userIDs. In addition to
> updates created by users in the list, explicit replies now also match
> and are streamed to consumers.
>
> Mentions, statuses that contain a given screen name ("Hello @user!"),
> but aren't explicit replies, are not matched.
>
> -John Kalucki
> Services, Twitter Inc.
>
>
