Raffi, Tweet id is a no-brainer. We understand that an linear incrementing number does not scale because at some point it must cycle back to 1.
Search is a different animal. When I do a Twitter search, I expect your system to tell me what is *happening* right now. I am NOT expecting your system to tell me what is *popular* right now. This popular tweet thing is diluting and violating your entire mission of "real-time". If I search for "earthquake" I want to see what is *happening* in real- time. I have no interest in seeing a 30-minute old tweet from @aplusk or @ev just because they are trusted accounts and the tweet is being retweeted a lot (to simplify the popularity algorithm). If people have a need to see popular tweets, you know what? That is an ideal service to be provided by a third-party developer/service. Twitter is real-time, and has defined real-time information. Stick to it. Don't dilute your mission. On Apr 6, 1:03 am, Raffi Krikorian <ra...@twitter.com> wrote: > we have the developer advocate we want, but, of course, please feel free to > reach out to taylor with your concerns and what you would like him to do to > help you all out. i'm sure he would welcome the help. > > as for what's going on behind the scenes, i'll describe it out as so: > > - tweet ID generation - this is a pure scalability problem that lays at > the heart of twitter being able to grow. unless i'm mistaken, in the end, > a > centralized way of generating tweet IDs that are strictly increasing by one > does not scale. the method that we generate tweet IDs, and therefore the > IDs themselves, will, almost probably, have to change. > - popular tweets in search - twitter is increasingly being relied upon to > be the place for relevant real-time information. most end-users would say > that a time indexed search stream is not as valuable. as you all can > probably tell, keeping a real time search index operational is hard enough, > but imagine keeping a service running that is simultaneously delivering > relevant results along with time indexed results. that's significantly > harder. > > those are the issues facing us. as i said, please bear with us -- once we > have weighed all these issues internally, we will of course, let everybody > know. we've heard the concerns, but, if there are new ones, please let us > know! > > On Mon, Apr 5, 2010 at 8:28 PM, Orian Marx (@orian) > <or...@orianmarx.com>wrote: > > > > > Raffi, one of the things that really stands out for me in what you are > > saying here is that there are lots of "moving pieces" that the team is > > trying to "align quickly". The question is, who and what is dictating > > the schedule? I get the sense that all the recent changes are parts of > > a bigger picture plan for Twitter, but the reality is that Twitter HQ > > has not conveyed a real sense of this bigger picture to the developer > > community - and it certainly hasn't conveyed why these recent changes > > need to "align quickly". So inevitably the situation at hand seems to > > be that some serious developer concerns effectively need to be pushed > > aside in order to meet some internal goals of Twitter that have not > > been made public. I can understand that as a choice that Twitter > > management might make. What I think would be unreasonable would be for > > Twitter to expect the developer community to not push back. > > > I think it's pretty clear that the "developer advocate" concept needs > > to be fleshed out more, and i'll try to push for that at Chirp. If > > anyone else is interested in helping make that discussion productive, > > lets get started :-) > > > On Apr 5, 8:45 pm, Raffi Krikorian <ra...@twitter.com> wrote: > > > to clarify (from my personal view), what taylor has provided to the team > > is > > > a clear view into what developers want / think / feel -- basically, a > > pulse > > > on the developer community. he's doing a fine job. and for these > > > particular issues, not only has he conveyed the feelings of our > > community, > > > but everybody on the team has also heard it personally. i hope we have > > more > > > to say about both these topics soon. as you can all imagine, there is a > > > myriad of moving pieces that we are all trying to get to align quickly -- > > > there are technical issues, there are the concerns of our developer and > > user > > > community, and then, of course, there are the overall objectives of > > Twitter, > > > Inc. getting them all to align is, at times, ridiculously difficult. > > > > On Mon, Apr 5, 2010 at 5:01 PM, Dewald Pretorius <dpr...@gmail.com> > > wrote: > > > > To be fair to Taylor, we may be expecting too much from his role. > > > > > When reading the job description of a Twitter Developer Advocate [1], > > > > the only traditional advocate responsibility listed there is > > > > "Represent developer needs when planning new API features and > > > > changes." > > > > > Now, if Taylor conveyed our objections to the Platform team, then he > > > > adequately executed that responsibility. I'm sure he did. > > > > > The rest of the responsibilities all speak in a Twitter to Developer > > > > direction, i.e., more a Communicator than an Advocate. > > > > > In particular, in the About This Job section, it says, "it is > > > > necessary to have an official voice regularly communicating with the > > > > community," which underlines Communicator instead of Advocate. > > > > > [1]http://dld.bz/7Z > > > > > On Apr 4, 9:39 pm, funkatron <funkat...@gmail.com> wrote: > > > > > Taylor, > > > > > > I'm about to vent. Sorry about this. > > > > > > At some point did you plan on addressing any of the numerous > > > > > complaints raised against making this anything other than opt-in? > > > > > > Several of us raised this, and you offered no response for 10 days. > > > > > See <http://groups.google.com/group/twitter-development-talk/ > > > > > browse_thread/thread/983086ae9935d50c/d4a8e0fbc0fee5c0? > > > > > lnk=gst&q=popular+search#d4a8e0fbc0fee5c0> > > > > > > When you *did* post, you didn't actually address any concerns, or say > > > > > "hey, I spoke with the API team. This is why it's going like this." > > > > > Like, say, an advocate of 3rd party developers would do. > > > > > > I'm not doing Twitter any favors; I realize that. I'm just the > > > > > developer of a tiny, old open source client whose been hacking away > > on > > > > > the API since spring of 2007. I'm not a strategic partner, and I > > don't > > > > > bring Twitter any value. No VC funding will be coming my way, I'm > > > > > afraid, and it doesn't make headlines on TechCrunch when I add a new > > > > > feature (ping.fm? I supported that in 2007). > > > > > > But what I would like is to be treated with some respect. If you post > > > > > something, and get significant pushback, I'd expect at *very* least > > > > > some explanation about why doing it the way you guys want to do it is > > > > > a great idea. If you are an advocate for 3rd party developers, as I > > > > > interpreted your title, then doing us the courtesy of not simply > > > > > ignoring/avoiding the concerns we voice seems like part of your job. > > > > > > It seems like you're doing a lot of selling of changes to *us*. > > That's > > > > > not an advocate -- that's an evangelist. If your role there is an > > > > > evangelist, then fine. You're doing a good job of ignoring the > > tougher > > > > > questions and sticking to company lines. > > > > > > The point here is that I used to cut the API crew a lot of slack > > > > > because I thought they at least weren't feeding us a line. I felt > > they > > > > > actually were aiming for transparency, but were just overworked. > > > > > > If this is the way things are gonna go with someone who is, > > > > > presumably, tasked with being *our* advocate, I think Twitter is > > > > > losing the thread. Maybe it doesn't matter for you guys financially, > > > > > and you'll go on and do Very Important Things and lots of people will > > > > > continue to view Twitter as Game-Changing Technology, but it sure is > > a > > > > > bummer for me. > > > > > > -- > > > > > Ed Finklerhttp://funkatron.com > > > > > @funkatron > > > > > AIM: funka7ron / ICQ: 3922133 / > > > > > XMPP:funkat...@gmail.com<xmpp%3afunkat...@gmail.com> > > <xmpp%3afunkat...@gmail.com <xmpp%253afunkat...@gmail.com>> > > > > > > On Apr 1, 8:53 pm, Taylor Singletary <taylorsinglet...@twitter.com> > > > > > wrote: > > > > > > > Hi Folks, > > > > > > > As indicated a few weeks ago, we're launching our new *beta* > > > > enhancements to > > > > > > search.twitter.com and the Search API today -- it's currently > > rolling > > > > out to > > > > > > our servers. Thank you all for your feedback. > > > > > > > *Key API Takeaways*: > > > > > > > - During the current phase, receiving "popular tweets" in your > > API > > > > search > > > > > > results is *OPT-IN*. You will not see the new top results in search > > > > unless > > > > > > you specify the *result_typ**e* parameter on your search query > > string. > > > > > > > - The result_type parameter takes one of three values: > > > > > > * *mixed* - receive both "popular tweets" and most recent > > tweets > > > > for the > > > > > > query. This is the equivalent of the future default behavior. > > > > > > * *popular* - receive only "popular tweets" for the query. > > > > > > * *recent* - receive only recent results for the query. This is > > the > > > > > > equivalent of the behavior you've come to expect until present > > > > > > > - Each tweet in a search result will now contain a metadata node, > > > > with a > > > > > > field called 'result_type' that indicates whether the tweet is > > > > "popular" or > > > > > > "recent". In the future, there may be other result_types. The > > metadata > > > > node > > > > > > will eventually contain other fields as well. > > > > > > > - In addition to result_type, the metadata node may also include > > a > > > > > > 'recent_retweets' field indicating the number of retweets the tweet > > has > > > > > > received recently, rounded to a reasonable integer. > > > > > > > - This metadata field will now appear in search results > > regardless of > > > > your > > > > > > OPT-IN status on the popular tweets feature. You don't have to do > > > > anything > > > > > > to receive this new metadata along with tweets in search results. > > In > > > > JSON, > > > > > > the metadata field is simply "metadata." In XML, you'll see it > > > > expressed as > > > > > > "<twitter:metadata>". > > > > > > > *Continued Discussion*: > > > > > > > To date, Twitter's real-time search has proven to be incredibly > > > > valuable. > > > > > > People, businesses and organizations have come to depend on finding > > out > > > > > > what's being discussed about a particular topic *right now*. > > > > > > > We've been really impressed at the integrations many of you have > > > > developed > > > > > > using the Search API. Whether it's offering search columns in a > > Twitter > > > > > > client, mapping #hashtags to search, or deep analysis of trends and > > > > brand > > > > > > monitoring, you've shown us what's possible with Twitter search. > > > > > > > With this new project, we want > > ... > > read more »- Hide quoted text - > > - Show quoted text -
