Dewald - agreed and seconded. On 6 April 2010 12:28, Dewald Pretorius <dpr...@gmail.com> wrote:
> 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>> > > > <xmpp%3afunkat...@gmail.com <xmpp%253afunkat...@gmail.com> < > xmpp%253afunkat...@gmail.com <xmpp%25253afunkat...@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 - >
