Raffi,
A bit advanced request. Would it be possible to attach list of
significant words and phrases present in the tweet. We could then use
this info to categorize tweets and even build a trends list on the
tweets aggregated by our apps.
In one of our apps, we use Yahoo Terms Extraction service t
Disambiguating short URLs and delivering the true URL and title would
be a real plus, not just for developers, but for the target of a URL.
While it does add a load to twitter's servers, it will save many, many
useless hits to the target.
Imagine 100,000 Twitter apps resolving each short URL found
+1 for it being optional as well -- keep the bandwidth to a minimum
for scenarios where it's not needed.
+1 for having short URLs' original (long) URL provided (perhaps also
an option?)
I understand. And I don't have anything against it (even if it will be
default), as long as it will be optional.
And we're all appreciating the library (and its Java implementation:
http://github.com/mzsanford/twitter-text-java).
On May 14, 3:47 pm, Raffi Krikorian wrote:
> all we're trying to d
>
> Besides, if this is the library used for web, you're not doing it
> right. :)
> For example, to mention URL parsing only, you don't check for valid
> domain names (e.g. www.test.failure is matched as URL),
> some characters are not recognized as part of a link (e.g. "|" in
> "http://translate.g
+1 for making this optional.
It's faster for mobile apps to do this themselves than download it.
Besides, if this is the library used for web, you're not doing it
right. :)
For example, to mention URL parsing only, you don't check for valid
domain names (e.g. www.test.failure is matched as URL),
s
Yes, this would be very cool. Any ideas on when this would be rolled
out?
1) It would be nice to have the profile_image_url in it as well. I can
imagine a lot of nice visual enhancements with that.
2) +1 for making it optional. A lot of people are suggesting
additional stuff, so maybe it would ev
+1 for it being optional as well. Whilst I will probably use it, it's
nice to be able to keep the bandwidth download to a minimum for
scenarios where it's not needed
On May 14, 1:52 am, Naveen Ayyagari wrote:
> +1 on the additional parameter to optionally request the data. Every
> byte counts fo
Indeed, it would be great to see this is the preview of UserStreams :)
+1 on the additional parameter to optionally request the data. Every
byte counts for mobile device battery life and download time.
--Naveen Ayyagari
@knight9
On May 13, 8:13 pm, Dewald Pretorius wrote:
> Raffi,
>
> This is all good, but can you please make the inclusion in the tweet
> payload o
Raffi,
This is all good, but can you please make the inclusion in the tweet
payload optional? Meaning, only include it if it is requested by an
additional parameter?
I, and I'm sure a lot of others, are already parsing the tweet text.
This is just going to consume additional bandwidth and not add
On May 13, 11:11 pm, Raffi Krikorian wrote:
> hey glenn.
>
> i think something went wrong in the copy and paste -- there should have been
> a space between the URL and the hashtag.
My bad. Back in my box then.
Cheers,
--
Glenn Gillen
http://glenngillen.com/
Raffi:
On May 13, 2:25 pm, Raffi Krikorian wrote:
> as shown above, we'll be parsing out all mentioned users, all lists, all
> included URLs, and all hashtags
This is an interesting step forward. The internationalisation
considerations can be sticky, though. I did some entity-parsing fro
yeah - i'm extremely sensitive to that not happening again. i'll keep that
in mind. i expect there may be another draft floated around before we start
to roll this out.
On Thu, May 13, 2010 at 11:14 PM, Rich wrote:
> I can see the inside some of the entities tag causing some
> developers some
I can see the inside some of the entities tag causing some
developers some problems as it's the same tag name as the status. Of
course all of us should be able to handle it, but just look what
happened with the extra user id tag inside a status
On May 13, 11:11 pm, Raffi Krikorian wrote:
> hey
hey glenn.
i think something went wrong in the copy and paste -- there should have been
a space between the URL and the hashtag.
On Thu, May 13, 2010 at 11:02 PM, glenn gillen wrote:
> Raffi,
>
> This follows on nicely from the presentation at Warblecamp last week
> discussing how difficult it
Glenn Gillen wrote:
> Without looking at how twitter.com would currently handle that example, I
> would have expected the url to be "http://dev.twitter.com/ #hot" and for
the
> tweet to contain no hashtag. If the hashtag always takes precedence I'd
have no
> way to link to the following without usi
Raffi,
This follows on nicely from the presentation at Warblecamp last week
discussing how difficult it is to do this right, and I think a
consistent approach across all clients (including twitter.com,
mobile.twitter, and 3rd party apps) should be priority number 1.
However looking at your example
18 matches
Mail list logo