Just wanted to give you an update on what's going on Twitter API land.
Firstly, my colleague on the API Team, Matt Sanford (@mzsanford), is in town from Seattle and working from the Twitter offices. We're trying to make the most of this in-person time to clear out administrivia and plan the next several weeks of work.
We've just finished cleaning up the list of API issues and enhancement requests (http://code.google.com/p/twitter-api/issues/list). We've closed, updated, re-prioritized, and generally attended to all tickets in the system. We have a number of fixes that are waiting on other parts of the Twitter engineering team to ship, and we've tried to clearly note which tickets aren't going to be dealt with until the next major release of the API.
Just yesterday, Matt finished working with our Operations team to move Twitter Search to Twitter's data center. The Search API should now return results more quickly, and we believe that we've increased our queries per second (QPS) capacity as well.
Additionally, Matt has been working with our User Experience (UX) team on a beta of OAuth support. The UX component of this work is almost complete, and we should be ready for our first deploy in the next week or ten days. The only potential blocker to this launch is the database schema changes it entails, which may be delayed by our Operations team as part of a broader set of database work.
Having completed performance tests to our satisfaction, a colleague of ours has been testing our HTTP-based firehose solution for correctness and stability. So far he's uncovered no issues, and we should be starting a beta period with this service in a matter of days. Apologies for not having the beta going by Thanksgiving, but hopefully this additional testing will mean fewer issues and a reduced time-to-production.
Our next major priority remains the rewrite of the Twitter API, which encompasses a variety of backend and frontend changes. We were hoping to have much of this work completed by the end of the year, and while I believe it'll be underway, I don't expect that it will be complete until early next year.
If you have any questions about our priorities and projects, please let us know. Thanks!
Thanks for the update! For those of us doing current development with the API, will the current version be kept around for a while (as a legacy version I guess) so that we may continue development as the new API is being rolled out? Or will it be a cut-over situation when the new API is released? I understand that eventually the current API version will be retired... but looking for guidance in the short-term.
On Tue, Dec 2, 2008 at 3:27 PM, Alex Payne <a...@twitter.com> wrote:
> Hi all,
> Just wanted to give you an update on what's going on Twitter API land.
> Firstly, my colleague on the API Team, Matt Sanford (@mzsanford), is > in town from Seattle and working from the Twitter offices. We're > trying to make the most of this in-person time to clear out > administrivia and plan the next several weeks of work.
> We've just finished cleaning up the list of API issues and enhancement > requests (http://code.google.com/p/twitter-api/issues/list). We've > closed, updated, re-prioritized, and generally attended to all tickets > in the system. We have a number of fixes that are waiting on other > parts of the Twitter engineering team to ship, and we've tried to > clearly note which tickets aren't going to be dealt with until the > next major release of the API.
> Just yesterday, Matt finished working with our Operations team to move > Twitter Search to Twitter's data center. The Search API should now > return results more quickly, and we believe that we've increased our > queries per second (QPS) capacity as well.
> Additionally, Matt has been working with our User Experience (UX) team > on a beta of OAuth support. The UX component of this work is almost > complete, and we should be ready for our first deploy in the next week > or ten days. The only potential blocker to this launch is the > database schema changes it entails, which may be delayed by our > Operations team as part of a broader set of database work.
> Having completed performance tests to our satisfaction, a colleague of > ours has been testing our HTTP-based firehose solution for correctness > and stability. So far he's uncovered no issues, and we should be > starting a beta period with this service in a matter of days. > Apologies for not having the beta going by Thanksgiving, but hopefully > this additional testing will mean fewer issues and a reduced > time-to-production.
> Our next major priority remains the rewrite of the Twitter API, which > encompasses a variety of backend and frontend changes. We were hoping > to have much of this work completed by the end of the year, and while > I believe it'll be underway, I don't expect that it will be complete > until early next year.
> If you have any questions about our priorities and projects, please > let us know. Thanks!
On Tue, Dec 2, 2008 at 12:33, Chad Etzel <jazzyc...@gmail.com> wrote: > Thanks for the update! For those of us doing current development with the > API, will the current version be kept around for a while (as a legacy > version I guess) so that we may continue development as the new API is being > rolled out? Or will it be a cut-over situation when the new API is > released? I understand that eventually the current API version will be > retired... but looking for guidance in the short-term.
> Thanks, > -Chad
> On Tue, Dec 2, 2008 at 3:27 PM, Alex Payne <a...@twitter.com> wrote:
>> Hi all,
>> Just wanted to give you an update on what's going on Twitter API land.
>> Firstly, my colleague on the API Team, Matt Sanford (@mzsanford), is >> in town from Seattle and working from the Twitter offices. We're >> trying to make the most of this in-person time to clear out >> administrivia and plan the next several weeks of work.
>> We've just finished cleaning up the list of API issues and enhancement >> requests (http://code.google.com/p/twitter-api/issues/list). We've >> closed, updated, re-prioritized, and generally attended to all tickets >> in the system. We have a number of fixes that are waiting on other >> parts of the Twitter engineering team to ship, and we've tried to >> clearly note which tickets aren't going to be dealt with until the >> next major release of the API.
>> Just yesterday, Matt finished working with our Operations team to move >> Twitter Search to Twitter's data center. The Search API should now >> return results more quickly, and we believe that we've increased our >> queries per second (QPS) capacity as well.
>> Additionally, Matt has been working with our User Experience (UX) team >> on a beta of OAuth support. The UX component of this work is almost >> complete, and we should be ready for our first deploy in the next week >> or ten days. The only potential blocker to this launch is the >> database schema changes it entails, which may be delayed by our >> Operations team as part of a broader set of database work.
>> Having completed performance tests to our satisfaction, a colleague of >> ours has been testing our HTTP-based firehose solution for correctness >> and stability. So far he's uncovered no issues, and we should be >> starting a beta period with this service in a matter of days. >> Apologies for not having the beta going by Thanksgiving, but hopefully >> this additional testing will mean fewer issues and a reduced >> time-to-production.
>> Our next major priority remains the rewrite of the Twitter API, which >> encompasses a variety of backend and frontend changes. We were hoping >> to have much of this work completed by the end of the year, and while >> I believe it'll be underway, I don't expect that it will be complete >> until early next year.
>> If you have any questions about our priorities and projects, please >> let us know. Thanks!
On Tue, Dec 2, 2008 at 2:27 PM, Alex Payne <a...@twitter.com> wrote:
> Additionally, Matt has been working with our User Experience (UX) team > on a beta of OAuth support. The UX component of this work is almost > complete, and we should be ready for our first deploy in the next week > or ten days.
Nifty.
Anything y'all can share about the thinking behind your OAuth UX decisions would be very helpful (not just how it ends up looking, but the sorts of things that were of concern, differerent options you considered, etc). That stuff's pure gold for others facing similar sorts of decisions. Not totally on topic, I'm just saying...
Sure, I'll talk to the UX folks about writing some of that up. OAuth is still in its early stages, and it seems most every organization that implements it ends up taking some slightly different paths.
On Tue, Dec 2, 2008 at 13:03, Christopher St John <ckstj...@gmail.com> wrote:
> On Tue, Dec 2, 2008 at 2:27 PM, Alex Payne <a...@twitter.com> wrote:
>> Additionally, Matt has been working with our User Experience (UX) team >> on a beta of OAuth support. The UX component of this work is almost >> complete, and we should be ready for our first deploy in the next week >> or ten days.
> Nifty.
> Anything y'all can share about the thinking behind your OAuth UX > decisions would be very helpful (not just how it ends up looking, but > the sorts of things that were of concern, differerent options you > considered, etc). That stuff's pure gold for others facing similar > sorts of decisions. Not totally on topic, I'm just saying...
The rewrite of the api has been on the cards for a while, and I've
kind of avoided doing any major work on Hahlo until I knew what was
happening, however it got the better of me last weekend and I began
work on Hahlo 4 which itself is a complete re-write.
Given that its a re-write how much do you see it changing as far as
how developers access it, ie. will the json,xml etc feeds still be the
same, will there be new/different parameters, or is the whole thing
just going to be completely new/shiny/fantastic?
And even though I do very much like the authentication system I wrote
on the weekend, I might start to investigate OAuth in preparation for
its appearance.
On Dec 3, 9:31 am, "Alex Payne" <a...@twitter.com> wrote:
> Sure, I'll talk to the UX folks about writing some of that up. OAuth
> is still in its early stages, and it seems most every organization
> that implements it ends up taking some slightly different paths.
> On Tue, Dec 2, 2008 at 13:03, Christopher St John <ckstj...@gmail.com> wrote:
> > On Tue, Dec 2, 2008 at 2:27 PM, Alex Payne <a...@twitter.com> wrote:
> >> Additionally, Matt has been working with our User Experience (UX) team
> >> on a beta of OAuth support. The UX component of this work is almost
> >> complete, and we should be ready for our first deploy in the next week
> >> or ten days.
> > Nifty.
> > Anything y'all can share about the thinking behind your OAuth UX
> > decisions would be very helpful (not just how it ends up looking, but
> > the sorts of things that were of concern, differerent options you
> > considered, etc). That stuff's pure gold for others facing similar
> > sorts of decisions. Not totally on topic, I'm just saying...
The main thing that's changing with the new release of the API is the URL scheme. We're cleaning things up, moving things around, making the whole thing more RESTful. I'll confer with @mzsanford and see about sharing our proposed set of URLs/methods.
Generally, though, we're still the same service and we've still got the same data to share with API clients, so the actual response formats themselves should change very little, save some new attributes popping up. Our main goal is moving the API onto a high-performance app server and optimizing such that we no longer have to burden all but the most aggressive clients with rate limiting.
On Wed, Dec 3, 2008 at 21:16, dean.j.robinson <Dean.J.Robin...@gmail.com> wrote:
> The rewrite of the api has been on the cards for a while, and I've > kind of avoided doing any major work on Hahlo until I knew what was > happening, however it got the better of me last weekend and I began > work on Hahlo 4 which itself is a complete re-write.
> Given that its a re-write how much do you see it changing as far as > how developers access it, ie. will the json,xml etc feeds still be the > same, will there be new/different parameters, or is the whole thing > just going to be completely new/shiny/fantastic?
> And even though I do very much like the authentication system I wrote > on the weekend, I might start to investigate OAuth in preparation for > its appearance.
> On Dec 3, 9:31 am, "Alex Payne" <a...@twitter.com> wrote: >> Sure, I'll talk to the UX folks about writing some of that up. OAuth >> is still in its early stages, and it seems most every organization >> that implements it ends up taking some slightly different paths.
>> On Tue, Dec 2, 2008 at 13:03, Christopher St John <ckstj...@gmail.com> wrote:
>> > On Tue, Dec 2, 2008 at 2:27 PM, Alex Payne <a...@twitter.com> wrote:
>> >> Additionally, Matt has been working with our User Experience (UX) team >> >> on a beta of OAuth support. The UX component of this work is almost >> >> complete, and we should be ready for our first deploy in the next week >> >> or ten days.
>> > Nifty.
>> > Anything y'all can share about the thinking behind your OAuth UX >> > decisions would be very helpful (not just how it ends up looking, but >> > the sorts of things that were of concern, differerent options you >> > considered, etc). That stuff's pure gold for others facing similar >> > sorts of decisions. Not totally on topic, I'm just saying...
Thanks for the updates - one of the things I noticed is that the
"archive" API method was marked as wontfix. I was wondering what this
means for the future of accessing our Twitter history?
Is this just something where we won't be able to export it in one
shot, but still have access to the history through successive API
calls?
Thanks,
dacort
On Dec 2, 12:27 pm, "Alex Payne" <a...@twitter.com> wrote:
> Just wanted to give you an update on what's going on Twitter API land.
> Firstly, my colleague on the API Team, Matt Sanford (@mzsanford), is
> in town from Seattle and working from the Twitter offices. We're
> trying to make the most of this in-person time to clear out
> administrivia and plan the next several weeks of work.
> We've just finished cleaning up the list of API issues and enhancement
> requests (http://code.google.com/p/twitter-api/issues/list). We've
> closed, updated, re-prioritized, and generally attended to all tickets
> in the system. We have a number of fixes that are waiting on other
> parts of the Twitter engineering team to ship, and we've tried to
> clearly note which tickets aren't going to be dealt with until the
> next major release of the API.
> Just yesterday, Matt finished working with our Operations team to move
> Twitter Search to Twitter's data center. The Search API should now
> return results more quickly, and we believe that we've increased our
> queries per second (QPS) capacity as well.
> Additionally, Matt has been working with our User Experience (UX) team
> on a beta of OAuth support. The UX component of this work is almost
> complete, and we should be ready for our first deploy in the next week
> or ten days. The only potential blocker to this launch is the
> database schema changes it entails, which may be delayed by our
> Operations team as part of a broader set of database work.
> Having completed performance tests to our satisfaction, a colleague of
> ours has been testing our HTTP-based firehose solution for correctness
> and stability. So far he's uncovered no issues, and we should be
> starting a beta period with this service in a matter of days.
> Apologies for not having the beta going by Thanksgiving, but hopefully
> this additional testing will mean fewer issues and a reduced
> time-to-production.
> Our next major priority remains the rewrite of the Twitter API, which
> encompasses a variety of backend and frontend changes. We were hoping
> to have much of this work completed by the end of the year, and while
> I believe it'll be underway, I don't expect that it will be complete
> until early next year.
> If you have any questions about our priorities and projects, please
> let us know. Thanks!
Yup, until some other under-the-hood stuff changes, we can't really hand out a user's archive in a single request/response in a timely and database-friendly fashion. You'll still have to page through to get a user's full archive, but with effectively non-existent rate limits, this should be much easier.
On Thu, Dec 4, 2008 at 12:01, Damon C <d.lifehac...@gmail.com> wrote:
> Hi Alex,
> Thanks for the updates - one of the things I noticed is that the > "archive" API method was marked as wontfix. I was wondering what this > means for the future of accessing our Twitter history?
> Is this just something where we won't be able to export it in one > shot, but still have access to the history through successive API > calls?
> Thanks,
> dacort
> On Dec 2, 12:27 pm, "Alex Payne" <a...@twitter.com> wrote: >> Hi all,
>> Just wanted to give you an update on what's going on Twitter API land.
>> Firstly, my colleague on the API Team, Matt Sanford (@mzsanford), is >> in town from Seattle and working from the Twitter offices. We're >> trying to make the most of this in-person time to clear out >> administrivia and plan the next several weeks of work.
>> We've just finished cleaning up the list of API issues and enhancement >> requests (http://code.google.com/p/twitter-api/issues/list). We've >> closed, updated, re-prioritized, and generally attended to all tickets >> in the system. We have a number of fixes that are waiting on other >> parts of the Twitter engineering team to ship, and we've tried to >> clearly note which tickets aren't going to be dealt with until the >> next major release of the API.
>> Just yesterday, Matt finished working with our Operations team to move >> Twitter Search to Twitter's data center. The Search API should now >> return results more quickly, and we believe that we've increased our >> queries per second (QPS) capacity as well.
>> Additionally, Matt has been working with our User Experience (UX) team >> on a beta of OAuth support. The UX component of this work is almost >> complete, and we should be ready for our first deploy in the next week >> or ten days. The only potential blocker to this launch is the >> database schema changes it entails, which may be delayed by our >> Operations team as part of a broader set of database work.
>> Having completed performance tests to our satisfaction, a colleague of >> ours has been testing our HTTP-based firehose solution for correctness >> and stability. So far he's uncovered no issues, and we should be >> starting a beta period with this service in a matter of days. >> Apologies for not having the beta going by Thanksgiving, but hopefully >> this additional testing will mean fewer issues and a reduced >> time-to-production.
>> Our next major priority remains the rewrite of the Twitter API, which >> encompasses a variety of backend and frontend changes. We were hoping >> to have much of this work completed by the end of the year, and while >> I believe it'll be underway, I don't expect that it will be complete >> until early next year.
>> If you have any questions about our priorities and projects, please >> let us know. Thanks!
