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

Reply via email to