How are characters indexed in the indices values of entities? My guess would be that they are indexed as Unicode code points--not bytes—and that the indexes refer to the text before entity expansion (“&” -> “&”) is done. Is that correct?
Like I mentioned in the previous thread, it would be very useful if we could use the entities construct when posting. First, it would help to mitigate problems when replying to somebody that has changed their username since the tweet you are replying to. Also, it would allow an application to clarify what is exactly in a URL. For example, “Check out http://example.org/foo.” should have the URL parsed without the trailing period, but currently Twitter considers the period to be part of the URL.
From other observations it seems like Twitter has already built a short-link expansion service that is used internally. Will expanded links be exposed via this entities mechanism anytime soon?
Regards,
Brian
Are there plans to include these features in streaming API?
Thanks!
On 26 maio, 19:22, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:
> Hi Developers,
>
> We released some new features today that I'll summarize briefly here.
>
> *Entities*
>
> Raffi's already introduced the concept of entities to you in a previous
> post:http://bit.ly/boHXYv
>
> You can now retrieve entities for tweets by specifying a
> include_entities=true parameter to statuses/home_timeline,
> statuses/user_timeline, statuses/friends_timeline, and statuses/mentions API
> calls to receive additional per-tweet payloads dissecting parse-able
> elements from the tweet body like @mentions, links, and hashtags. It's
> really cool! Some examples of how entities are represented can be found
> here:http://dev.twitter.com/pages/tweet_entities
>
> *Retweets in Timelines*
> *
> *Many developers have asked for merged timelines including native retweets;
> for backwards-compatibility reasons this hasn't been possible in the past.
> Now you can include a include_rts=true parameter to statuses/user_timeline,
> statuses/friends_timeline, and statuses/mentions API calls to receive
> retweets inline in the payload.
>
> *OAuth callbacks with non-standard URI schemes*
> While you still can't set your default oauth_callback in your client
> application record to a URI schemes that aren't of the http or https
> variety, you can now dynamically set your oauth_callback on the
> request_token step of the OAuth dance to custom URI schemes. This is useful
> when your application is a web browser itself, or has the capability of
> registering custom URI schemes on the host operating system; a great, almost
> friction-free solution for those weary of the out-of-band OAuth flow.
>
> Since these features are new, we would appreciate any comments, suggestions,
> or notes on any bugs you discover while using them.
>
> Some relevant updated documentation:http://dev.twitter.com/doc/get/statuses/mentionshttp://dev.twitter.com/doc/get/statuses/friends_timelinehttp://dev.twitter.com/doc/get/statuses/home_timelinehttp://dev.twitter.com/doc/get/statuses/public_timeline
Thanks,
Jebu
> > Some relevant updated documentation:http://dev.twitter.com/doc/get/statuses/mentionshttp://dev.twitter.co...
Cool. There is just one issue in combination with the new
"include_rts" flag; I've opened a ticket here:
http://code.google.com/p/twitter-api/issues/detail?id=1652
> *Retweets in Timelines*
> *
> *Many developers have asked for merged timelines including native retweets;
> for backwards-compatibility reasons this hasn't been possible in the past.
> Now you can include a include_rts=true parameter to statuses/user_timeline,
> statuses/friends_timeline, and statuses/mentions API calls to receive
> retweets inline in the payload.
Sweet. Thanks for finally implementing this!
- David
Thanks. The entities in retweets will function for all retweets from
now on. If you query a timeline which has
retweets in it [1] you should find the entities are included and with
the correct offsets.
1. twurl "/1/statuses/user_timeline.xml?
id=themattharris&count=5&include_entities=true&include_rts=true&trim_user=true"
Are there any plans to extend this to all returned tweets (search for
example)? It seems its usefulness is suspect until it is available
across the board due to the fact that a parser will have to exist
client side until that happens.
Doesn't work for JSON, only for XML. Have added a comment to the issue.
> Finally, it would be super-helpful to have a changelog on
> dev.twitter.com—especially if it came with an rss feed!
+1