Our front-end team has been thinking about this lately. Nothing certain yet, but we'll consider it!
On Fri, Feb 20, 2009 at 09:49, Mislav <[email protected]> wrote: > > My user script (http://userscripts.org/scripts/show/24398) offers an > option to poll the API for new updates and insert them in the page -- > what every normal twitter client does, basically. > > Only this twitter "client", being a user script, hasn't got a UI of > its own -- the twitter.com site is the UI. When a new update is > detected, I receive it as JSON but then I have to go through a painful > step of generating HTML markup to match the markup of Twitter.com for > a single update. This code can be seen here: http://gist.github.com/67592 > > This step is also very fragile: when Twitter.com changes markup (which > it does a lot lately), this script generates obsolete HTML. > > If the API for getting updates provided HTML fragments instead of > JSON, I could simply insert the received HTML in the page. > > Will this extension of the API ever be considered? > > Technically, this should be trivial to implement -- the response would > be a rendered view partial. In fact, Twitter already implemented it as > part of the Ajax API for the web. When you post an update from the > main form on the site, an Ajax request submits the update and gets > JSON in return -- only this JSON includes nothing more than a few > properties with HTML fragments to be inserted in appropriate places. > > Another place where Twitter.com returns HTML fragments for Ajax > requests is pagination. The unreleased version of Endless Tweets (my > user script) already uses this web API to preload pages while the user > scrolls down. > > Thanks > -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
