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
+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),
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
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 ra...@twitter.com wrote:
all
+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?)
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
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
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
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 using a
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 gl...@rubypond.com wrote:
Raffi,
This follows on nicely from the presentation at Warblecamp last week
discussing
I can see the text 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
Raffi:
On May 13, 2:25 pm, Raffi Krikorian ra...@twitter.com 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
On May 13, 11:11 pm, Raffi Krikorian ra...@twitter.com 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,
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
+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 dpr...@gmail.com wrote:
Raffi,
This is all good, but can you please make the inclusion in the
Indeed, it would be great to see this is the preview of UserStreams :)
+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 nav...@getsocialscope.com wrote:
+1 on the additional parameter to optionally request the
17 matches
Mail list logo
