we obviously feel that users want the most relevant tweets first (the
use of "popular" is unfortunate here). and the web interface of search.twitter.com
has begun an evolution in that direction.
it's still unclear what Twitter is going to do with the API (hence the
silence), however, to go with your argument: "time indexed" search is,
potentially, something a third party service could do. we do provide
the streaming API to get much-better-than-search-real-time results.
On Apr 6, 2010, at 4:28 AM, Dewald Pretorius <dpr...@gmail.com> wrote:
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
If I search for "earthquake" I want to see what is *happening* in
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
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
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
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
that a time indexed search stream is not as valuable. as you
probably tell, keeping a real time search index operational is
but imagine keeping a service running that is simultaneously
relevant results along with time indexed results. that's
those are the issues facing us. as i said, please bear with us --
have weighed all these issues internally, we will of course, let
know. we've heard the concerns, but, if there are new ones, please
On Mon, Apr 5, 2010 at 8:28 PM, Orian Marx (@orian)
Raffi, one of the things that really stands out for me in what you
saying here is that there are lots of "moving pieces" that the
trying to "align quickly". The question is, who and what is
the schedule? I get the sense that all the recent changes are
a bigger picture plan for Twitter, but the reality is that Twitter
has not conveyed a real sense of this bigger picture to the
community - and it certainly hasn't conveyed why these recent
need to "align quickly". So inevitably the situation at hand seems
be that some serious developer concerns effectively need to be
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
Twitter to expect the developer community to not push back.
I think it's pretty clear that the "developer advocate" concept
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
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
a clear view into what developers want / think / feel --
on the developer community. he's doing a fine job. and for these
particular issues, not only has he conveyed the feelings of our
but everybody on the team has also heard it personally. i hope
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
there are technical issues, there are the concerns of our
community, and then, of course, there are the overall objectives of
Inc. getting them all to align is, at times, ridiculously
On Mon, Apr 5, 2010 at 5:01 PM, Dewald Pretorius <dpr...@gmail.com>
To be fair to Taylor, we may be expecting too much from his role.
When reading the job description of a Twitter Developer Advocate
the only traditional advocate responsibility listed there is
"Represent developer needs when planning new API features and
Now, if Taylor conveyed our objections to the Platform team,
adequately executed that responsibility. I'm sure he did.
The rest of the responsibilities all speak in a Twitter to
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
community," which underlines Communicator instead of Advocate.
On Apr 4, 9:39 pm, funkatron <funkat...@gmail.com> wrote:
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
When you *did* post, you didn't actually address any concerns,
"hey, I spoke with the API team. This is why it's going like
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
the API since spring of 2007. I'm not a strategic partner, and I
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
feature (ping.fm? I supported that in 2007).
But what I would like is to be treated with some respect. If
something, and get significant pushback, I'd expect at *very*
some explanation about why doing it the way you guys want to do
a great idea. If you are an advocate for 3rd party developers,
interpreted your title, then doing us the courtesy of not simply
ignoring/avoiding the concerns we voice seems like part of your
It seems like you're doing a lot of selling of changes to *us*.
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
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
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
and you'll go on and do Very Important Things and lots of
continue to view Twitter as Game-Changing Technology, but it
bummer for me.
AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com<XMPP
On Apr 1, 8:53 pm, Taylor Singletary
As indicated a few weeks ago, we're launching our new *beta*
search.twitter.com and the Search API today -- it's currently
our servers. Thank you all for your feedback.
*Key API Takeaways*:
- During the current phase, receiving "popular tweets" in your
results is *OPT-IN*. You will not see the new top results in
you specify the *result_typ**e* parameter on your search query
- The result_type parameter takes one of three values:
* *mixed* - receive both "popular tweets" and most recent
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.
equivalent of the behavior you've come to expect until present
- Each tweet in a search result will now contain a metadata
field called 'result_type' that indicates whether the tweet is
"recent". In the future, there may be other result_types. The
will eventually contain other fields as well.
- In addition to result_type, the metadata node may also
'recent_retweets' field indicating the number of retweets the
received recently, rounded to a reasonable integer.
- This metadata field will now appear in search results
OPT-IN status on the popular tweets feature. You don't have to
to receive this new metadata along with tweets in search
the metadata field is simply "metadata." In XML, you'll see it
To date, Twitter's real-time search has proven to be incredibly
People, businesses and organizations have come to depend on
what's being discussed about a particular topic *right now*.
We've been really impressed at the integrations many of you have
using the Search API. Whether it's offering search columns in a
client, mapping #hashtags to search, or deep analysis of
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 -
To unsubscribe, reply using "remove me" as the subject.