On Dec 2, 7:36 pm, John Kalucki wrote:
> This is documented, supported and subject to as much change or stasis as any
> other Twitter feature.
>
> The entire tweet is given to avoid an extra round-trip in rendering
> timelines. Many our results are denormalized in this way, as a fully
> normaliz
This is documented, supported and subject to as much change or stasis as any
other Twitter feature.
The entire tweet is given to avoid an extra round-trip in rendering
timelines. Many our results are denormalized in this way, as a fully
normalized schema delivered via an Internet service would be
I've been looking at data acquired from the "sample" feed. In those
tweets, I've discovered something, and I wanted to run it by Twitter
and see if this is an official, documented API feature.
When a tweet is a retweet using the retweet button on the web page,
there is an extra key-value pair in a
Thing is the new RT api simply does not express the same thing the
classic RT @xxx is :
It's a subset of a big set of meanings : [ "Like" , "Forward" ,
"Comment", "Thanks", "Emphasis", "Reply" ] (and I'm sure there are a
lot more uses)
The rich semantic of classic RTs make them sometime difficult
> > Speaking for TTYtter only, while I'll support receiving retweets, I am
> > unhappy with the API as it currently exists and retweets received will
> > be canonized into the older format (and retweets sent will be done
> > programmatically in the older fashion instead of through the retweet
> >
> Does twitter have plans to prevent status messages (just like they
> prevent duplicates) that use the old retweet format and in effect,
> force applications to upgrade to using the retweet api?
Ignoring how steamed people would be if that happened, I doubt it, because
there are plenty of ways t
> I am unhappy with the API as it currently exists and retweets received will
> be canonized into the older format (and retweets sent will be done
> programmatically in the older fashion instead of through the retweet
> methods). I suspect there are other app authors who will also do something
> s
On Thu, Nov 12, 2009 at 08:00:56AM -0800, Cameron Kaiser wrote:
> Speaking for TTYtter only, while I'll support receiving retweets, I am
> unhappy with the API as it currently exists and retweets received will
> be canonized into the older format (and retweets sent will be done
> programmatically
I think I've added to the confusion. Sorry about making things worse.
I was coming from a strictly search viewpoint. But Retweet is not so
simple!
There are lots of different places that Tweets are rendered: Various
timelines, Search, Streaming, SMS, etc. etc. Various renderings and
search mechan
> My concern is that there is nothing to force users to upgrade their
> twitter applications, there is nothing to force applications to use
> the retweet API (although, I agree most probably will) and for an
> indeterminate amount of time users will still "retweet" by prefixing
> their tweets with
> Change breaks both expectations and code. It is inevitable.
I agree with this statement. However, there seems to be some confusion
over whether retweets will still be prefixed with RT. If retweets are
no longer prefixed with RT, then I do not understand why that change
is being made. You could d
The Retweet feature has many possible realizations. We've tried nearly
every possible combination of all the functional dimensions as the
feature evolved over many months. It's possible that what you saw was
based on a snapshot of the current state of the feature, and the
feature subsequently chan
In the examples that are shown in the developers preview for the RT
api these where prefixed with RT, was this done on purpose or did this
change after the examples where made public?
On Nov 11, 6:48 pm, John Kalucki wrote:
> Search is aware of the need for a retweet operator, but the feature is
Search is aware of the need for a retweet operator, but the feature is
unscheduled and completely speculative.
In any case, Search will become less useful for this sort of
repetitive complete corpus search. If you need all of something, or a
sample of something, you should be moving to the Stream
Thanks John,
this means that my app won't work anymore!
streaming api makes my life very hard
hence i need to search for links and then extract them, this is very
resource demanding to do on the fly
while with search API i can search then extract and then search again
i could use queue system but
Retweets do not modify the original text in any way. There is no RT to
search upon.
There is a feed of all public retweets on the Streaming API, but it is
not generally available. Instead, you can request a sample of all
statuses and filter for those that are retweets.
-John Kalucki
http://twitt
and now i hear from someone who already has the new RT
that statuses aren't prefixed!
so are they or aren't they prefixed?
I'd love to get formal answer or reference to formal info on this
On Nov 11, 6:58 pm, Yaniv Golan wrote:
> oh...
> that's cool :)
> Thanks i really got wםrried for a sec
>
oh...
that's cool :)
Thanks i really got wםrried for a sec
On Nov 11, 5:08 pm, Walter Smulders wrote:
> With the retweet function the status text will still be prefixed with
> RT
>
> On Nov 11, 11:59 am, Yaniv Golan wrote:
>
> > Hi
> > I'm using twitter search API to search statuses with retwee
With the retweet function the status text will still be prefixed with
RT
On Nov 11, 11:59 am, Yaniv Golan wrote:
> Hi
> I'm using twitter search API to search statuses with retweet
> expressions (e.g RT VIA) with the link filter
> i search the documentation over and over but i can't find any sol
19 matches
Mail list logo
