On 04/11/2010 09:33 PM, Nick Arnett wrote:
> On Sun, Apr 11, 2010 at 5:14 PM, John Kalucki wrote:
>
>>
>> This is useful stuff for dealing with infinite sequences of events -- like,
>> picking a random example, the insertion of new tweets into a materialized
>> timeline (a cache of the timeline v
On Sun, Apr 11, 2010 at 5:14 PM, John Kalucki wrote:
>
> This is useful stuff for dealing with infinite sequences of events -- like,
> picking a random example, the insertion of new tweets into a materialized
> timeline (a cache of the timeline vector).
The Twitter stream is an infinite sequenc
actly Once
>> behavior with little (usually no) overhead. Is that a correct
interpretation
>> of what you were saying?
>>
>>
>>
>> Thanks,
>>
>> Brian
>>
>>
>>
>>
>>
>> From: twitter-development-talk@googlegroups.co
000 ms (from what you said below), you are almost definitely
> getting
> >> At Least Once behavior if Twitter is operating normally, and you can use
> >> that information to get At Least Once behavior that emulates Exactly
> Once
> >> behavior with little (usually no) o
hat a correct interpretation
>> of what you were saying?
>>
>>
>>
>> Thanks,
>>
>> Brian
>>
>>
>>
>>
>>
>> From: twitter-development-talk@googlegroups.com
>> [mailto:twitter-development-t...@googlegroups.com] On Be
gt;
>
> I think this is information that would be useful to have added to the API
> documentation, as I know many applications are taking a much more naive
> approach to pagination.
>
>
>
> Thanks again,
>
> Brian
>
>
>
> *From:* twitter-development-talk@goo
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs are
sequenced
Folks are making a lot of incorrect assumptions about the Twitter
architecture, especially around how we materialize and present timeline
vectors and just wh
egroups.com *On Behalf Of *John
> Kalucki
> *Sent:* Friday, April 09, 2010 1:20 PM
>
> *To:* twitter-development-talk@googlegroups.com
> *Subject:* Re: [twitter-dev] Re: Upcoming changes to the way status IDs
> are sequenced
>
>
>
> Folks are making a lot of incorrect assumpt
a much more naive
approach to pagination.
Thanks again,
Brian
From: twitter-development-talk@googlegroups.com On Behalf Of John Kalucki
Sent: Friday, April 09, 2010 1:20 PM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs
On 04/09/2010 11:20 AM, John Kalucki wrote:
[snip]
>
> In the end, since_id issues go away on the Streaming API, and other than
> around various start-up discontinuities, you can ignore this issue. I'll be
> talking about Rough Ordering, among other things Streaming, at the Chirp
> conference.
Folks are making a lot of incorrect assumptions about the Twitter
architecture, especially around how we materialize and present timeline
vectors and just what QoS we're really offering. This new scheme does not
significantly, or perhaps even observably, make the existing issues around
since_id any
On Thu, Apr 08, 2010 at 05:03:29PM -0700, Naveen wrote:
> However, I wanted to be clear and feel it should be made obvious that
> with this change, there is a possibility that a tweet may not be
> delivered to client if the implementation of how since_id is currently
> used is not updated to cover
: [twitter-dev] Re: Upcoming changes to the way status IDs are
sequenced
It's a possibility, but by no means a probability. Note that you can mitigate
this by using the newest tweet that is outside your "danger zone". For example
in a sequence of tweets t1, t2 ... ti ... t
= max({ id(t), for all t in T}).
>
> > > 5. Goto 2.
>
> > > Will I be guaranteed not to skip over any tweets in the timeline using
> > this logic? If not, what do I need to do to ensure I get them all?
>
> > > Thanks,
>
> > > Brian
>
&
gt;
> > Thanks,
> >
> > Brian
> >
> > From: twitter-development-talk@googlegroups.com [mailto:
> twitter-development-t...@googlegroups.com] On Behalf Of Mark McBride
> > Sent: Thursday, April 08, 2010 5:10 PM
> > To: twitter-development-talk@googlegroups.
oups.com
> [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Mark McBride
> Sent: Thursday, April 08, 2010 5:10 PM
> To: twitter-development-talk@googlegroups.com
> Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs are
> sequenced
>
> Thank y
...@googlegroups.com] On Behalf Of Mark McBride
Sent: Thursday, April 08, 2010 5:10 PM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs are
sequenced
Thank you for the feedback. It's great to hear about the variety of use
On Thu, Apr 8, 2010 at 5:39 PM, Nick Arnett wrote:
>
> I'd love to see an example of two bots replying to each other and looking
> entirely natural!
>
> We all knew this sort of thing was going on, removing the pesky humans from
> the loop, but I always thought it was unintentional.
>
> There's a
On Thu, Apr 1, 2010 at 10:47 AM, Dewald Pretorius wrote:
> Mark,
>
> It's extremely important where you have two bots that reply to each
> others' tweets. With incorrectly sorted tweets, you get conversations
> that look completely unnatural.
I'd love to see an example of two bots replying to e
Thank you for the feedback. It's great to hear about the variety of use
cases people have for the API, and in particular all the different ways
people are using IDs. To alleviate some of the concerns raised in this
thread we thought it would be useful to give more details about how we plan
to gene
On 04/05/2010 12:55 AM, Tim Haines wrote:
> This made me laugh. Hard.
>
> On Fri, Apr 2, 2010 at 6:47 AM, Dewald Pretorius wrote:
>
>> Mark,
>>
>> It's extremely important where you have two bots that reply to each
>> others' tweets. With incorrectly sorted tweets, you get conversations
>> that
This made me laugh. Hard.
On Fri, Apr 2, 2010 at 6:47 AM, Dewald Pretorius wrote:
> Mark,
>
> It's extremely important where you have two bots that reply to each
> others' tweets. With incorrectly sorted tweets, you get conversations
> that look completely unnatural.
>
> On Apr 1, 1:39 pm, Mark
When?
On Mar 26, 4:41 pm, Taylor Singletary
wrote:
> Hi Developers,
>
> It's no secret that Twitter is growing exponentially. The tweets keep coming
> with ever increasing velocity, thanks in large part to your great
> applications.
>
> Twitter has adapted to the increasing number of tweets in wa
On Apr 1, 4:34 pm, Aki wrote:
> I'm developing desktop Twitter client. I think accurate sorting is
> needed, because the order of tweets may look different on every
> application without accurate sorting. It's not that it would totally
> kill my Twitter client, but I take accurate presentation of
I'm developing desktop Twitter client. I think accurate sorting is
needed, because the order of tweets may look different on every
application without accurate sorting. It's not that it would totally
kill my Twitter client, but I take accurate presentation of tweets
seriously, and I think it would
Ed,
I dunno. Maybe sub-second sorting resolution for tweets is also
important for kids who grew up with cell phones and texting, and can
type *really* fast on an iPhone.
On Apr 1, 4:41 pm, "M. Edward (Ed) Borasky" wrote:
> On Apr 1, 10:47 am, Dewald Pretorius wrote:
>
> > Mark,
>
> > It's extre
On Apr 1, 9:39 am, Mark McBride wrote:
> Just out of curiosity, what applications are you building that require
> sub-second sorting resolution for tweets?
>
> ---Mark
Twitter's capacity planning? ;-)
--
To unsubscribe, reply using "remove me" as the subject.
On Apr 1, 10:47 am, Dewald Pretorius wrote:
> Mark,
>
> It's extremely important where you have two bots that reply to each
> others' tweets. With incorrectly sorted tweets, you get conversations
> that look completely unnatural.
Uh ... bots talking to each other on Twitter? Is this something I c
Mark,
It's extremely important where you have two bots that reply to each
others' tweets. With incorrectly sorted tweets, you get conversations
that look completely unnatural.
On Apr 1, 1:39 pm, Mark McBride wrote:
> Just out of curiosity, what applications are you building that require
> sub-se
Just out of curiosity, what applications are you building that require
sub-second sorting resolution for tweets?
---Mark
http://twitter.com/mccv
On Wed, Mar 31, 2010 at 11:01 PM, Aki wrote:
> It actually makes sense to use tweet ID to sort tweets, because
> timestamp is not a valid source o
It actually makes sense to use tweet ID to sort tweets, because
timestamp is not a valid source of information for accurate sorting.
It is a very common case to have multiple tweets posted at the exact
same second, and it is not possible to reproduce the correct ordering
of tweets on the client sid
It's really bad application design practice to assign any significance
to the primary key of an entity, except for a means to uniquely
identify each member of the entity.
--
To unsubscribe, reply using "remove me" as the subject.
The ability to create apps like http://www.tweespeed.com/ as a result
of a few quick APIs to get the difference between two status IDs is
really nice.
Perhaps even if status IDs are not sequential there could be some kind
of a an API method like tweetCount(firstID, secondID) that if given
two stat
On Wed, Mar 31, 2010 at 07:30:00AM -0700, eugene.man...@gmail.com wrote:
> Second that. Our app continuously retrieves feeds of individual users
> and lists. Monotonically increasing are required to be able to do that
> (using since_id).
[...]
Since the most significant bits are generated from a t
Second that. Our app continuously retrieves feeds of individual users
and lists. Monotonically increasing are required to be able to do that
(using since_id).
Please provide an alternative for this use case in case you change
your id generation scheme.
Thanks!
On Mar 26, 1:57 pm, Naveen wrote:
Taylor,
We too rely heavily on the sequential, increasing nature of standard
tweet and DM IDs. Are both are in scope here?
While it is straightforward to can change code to sort and compare on
dates, this will be a major undertaking for our application. I suspect
many other applications are in th
+1 ;-)
On 26 mar, 21:57, "bob.hitching" wrote:
> +1 on the need to maintain support for since_id in the Search API
>
> On Mar 27, 7:41 am, Taylor Singletary
> wrote:
>
> > Hi Developers,
>
> > It's no secret that Twitter is growing exponentially. The tweets keep coming
> > with ever increasing v
We're relying on the ID being sequention for a number of purposes:
1) Counting elapsed tweets to estimate tweet rates to feed back into
count parameter to backtrack when restarting streaming API/Shadow -
how will we be able to do that without sequential IDs???
2) Indexing and sorting pages of twe
I'm relying on increasing status_id's for indexing/sorting tweets and
on using since_id (for saving traffic.) Any change to this will break
my mobile Twitter client.
As long as the status_id's are increasing for sequential tweets, I'm
fine - however, I don't really understand the need of "random g
So, I guess for the since_id issue, it boils down to this question:
Regarding the since_id parameter, when you (Twitter) flip the switch
on the new ID format, will I (as a developer) have to change any of my
code in order for it to function the way it does now? This question
applies equally for bo
> So I think we need to allow Twitter some leeway here.
I apologize if my tone came off badly; it was not intended. I've just
had bumpy rides using timestamps for coordination in distributed
systems (less cool ones than space flight), so this worried me a
little. In the end, whatever Twitter decid
Will you still be able to look at two relative IDs and tell which one
came first and which one came second?
To unsubscribe from this group, send email to
twitter-development-talk+unsubscribegooglegroups.com or reply to this email
with the words "REMOVE ME" as the subject.
My applications will have an impact in the SQL queries. Right now, to
display tweets in reverse chronological order and with pagination, my
query has something like this:
SELECT * FROM
tweets
INNER JOIN mytable on tweets.id = mytable.tweet_id
GROUP BY tweets.id
ORDER BY tweets.id DESC
LIMIT 100, 2
My Desktop Client is also depending on since_id right now in order to
display the user all new tweets since he logged out. Also without
since_id and max_id it's not really possible to implemente a "more"
link at the bottom.
Personally, for my needs it would be enough if since_id and max_id
would b
Good morning
hope all are well,
Like TweeSpeed and also assumingly
http://popacular.com/gigatweet/
I have to little apps deriving the volume of tweets on twitter from
the ID
http://twopular.com/labs/tweetMania
http://twopular.com/labs/countingTweets
With the announced change visualization of
That's awesome! How far back does your dataset go? Do you have the
Michael Jackson spike?
On Mar 26, 2:01 pm, jerememonteau wrote:
> Whoops, accidentally just replied to author the first time...but...
>
> I build this little site about 9 months ago, depending on the
> monotonically increasing nat
On Mar 26, 4:01 pm, Josh Bleecher Snyder wrote:
> Having a universal counter is untenable, but having occasional,
> undiagnosable, unreproducible glitches also sucks. :) Thinking out
> loud, perhaps there is some middle ground -- a way to have generally
> monotonically increasing ids globally, and
Hi-
Thanks for the heads-up. I have a couple of questions: Most
importantly: when will this change happen?
I understand that we should not depend on the format of the ID, but
since we currently do, can we get more exact information on the new
format? Is there going to be a very large discontinuou
Hi Taylor (et al.),
There are two reasons to think that, with the scheme you propose,
tweet ids will not necessarily be monotonically increasing.
Naveen hit the first:
> It seems if two messages are posted at very close to same time, they may not
> be sequential since the bottom bits will be ran
So will they be monotonically increasing? That seems to be the key
question. If they're not necessarily monotonic with respect to their
date, then it seems like it would be a pretty painful change.
Isaiah
To unsubscribe from this group, send email to
twitter-development-talk+unsubscribegoogleg
Hi,
>From a practical developer point of view having "growing" IDs are very
helpful.
In many common DB operations greatly simplifies things for the
developers. (Most application with local storage or cache need one key
less. Or complex queries need fewer values in a temporary table.) This
leads t
Hi,
>From a practical development point of view having "growing" IDs are
very helpful.
With many common database operations greatly simplifies things for the
developers. (Most application with local storage or cache need one key
less. Or complex queries need fewer values in a temporary table.) Th
+1 on IDs being increasing. Sequential doesn't matter to me. I don't
actually trust passing since_id to Twitter and having them handle the
limiting of my result list. I've gotten into trouble when that feature
suddenly quit being recognized and my code wasn't defensive enough to
double-check since_
I am still a little unclear if we will be able to determine the correct
since_id to pass to the api by always looking for the largest tweet id we have
seen.
It seems if two messages are posted at very close to same time, they may not be
sequential since the bottom bits will be randomly generat
> So it would be cool if some way were provided for me to gauge tweet
> volumes at regular intervals (currently every 2 minutes).
Take a look to Tweespeed http://www.tweespeed.com
But with the change annonced, this site is dead at term ...
pas...@tweespeed
On Mar 26, 10:01 pm, jerememonteau wr
I am using since_id in my app to know when to stop paging on both the
api & search api. My code expects the id to be sequential.
RT @jkalucki: Primary-Key-Density-Change-Pocalypse. Of total doom.
To unsubscribe from this group, send email to
twitter-development-talk+unsubscribegooglegroups.com o
A quick clarification for you all since there seems to be the most concern
around using since_id as a parameter:
since_id will work as well as it does today as a result of this change.
Also, a reminder that the actual integer format of the tweet IDs will not be
changing. They'll still be unsigned
I hope you're right, but my app design depends on since_id, and before I
proceed further I want to be sure that I will not have to rebuild when this
new format comes in.
On 26 March 2010 21:09, Ray Krueger wrote:
> I would think that this would make no difference for since_id. The
> purpose of s
I would think that this would make no difference for since_id. The
purpose of since_id is for us to the API "give me the data I need
that's happened since this id". Don't assume it's implemented as
"select * from tweets were id > since_id". :)
On Mar 26, 4:01 pm, Michael Bleigh wrote:
> To those
Can we assume a status ID will be unique or not?
It's unclear here.
If not, it should be a big problem for most apps.
- Satoshi
On Mar 27, 5:41 am, Taylor Singletary
wrote:
> If you've been trying to divine meaning from status IDs aside from their
> role as a primary key, you won't be able to
Especially on mobile devices, it's significantly faster to sort tweets
by comparing the long long representation of an ID rather than by the
date. It's also more accurate, as two tweets that come in at the exact
same second will still be sorted in the correct order.
Steve
On Mar 26, 4:41 pm, Tayl
To those voicing concerns about since_id I believe the key word is
that they will no longer be *sequential*, something entirely different
from them no longer being *increasing*. Since ID is a core part of the
Twitter API that I very much doubt will be in jeopardy from this
change. Twitter devs feel
Whoops, accidentally just replied to author the first time...but...
I build this little site about 9 months ago, depending on the
monotonically increasing nature of tweet IDs :
http://www.tweelocity.com
This is a fun graph :
http://tweelocity.com/chart/60/300/
So it would be cool if some way w
Hi Taylor!
Please comment on how this change will affect this bug:
http://code.google.com/p/twitter-api/issues/detail?id=1529
Hopefully, the timestamp portion of the ID will allow since_id to work
correctly when load increases.
-ch
On Mar 26, 1:41 pm, Taylor Singletary
wrote:
> Hi Developers
We do not require that ids be sequential, but if the ids are not
monotonically increasing it cause some issue with how we manage
since_ids..
i.e. if a message posted by userA, 1 ns after userB, we would assume
userB has a higher id than userA. While it may seem like nitpicking,
wouldn't there a ch
+1 on the need to maintain support for since_id in the Search API
On Mar 27, 7:41 am, Taylor Singletary
wrote:
> Hi Developers,
>
> It's no secret that Twitter is growing exponentially. The tweets keep coming
> with ever increasing velocity, thanks in large part to your great
> applications.
>
>
I second this request, as a mobile developer since_id is essential for
caching old tweets and only retreiving new tweets.
since_id is invaluable. You say " in most cases the new approach we
will take will not result in any noticeable differences " does that
mean you will still handle a since_id b
67 matches
Mail list logo
