Sure, I'll justify this mroe...
One of our apps receives updates via the Streaming API and the various
REST api methods (mentions, user timelines, friends/home timelines).
We collect data as JSON as it's to date been faster and mor compact
than alternatives... we can also then go on to use this
Well, you're not making use of JSON as JSON, and instead use brute-force
methods to extract parts of it... I think it's a bit unfair to request that
change to be made, as it would complicate things for everyone doing real
JSON-to-OO mapping. Just my 2c.
And no, retweet_status is perfectly valid -
We use JSON thoughout... as JSON and also parsing to db fields... I
love that JSON converts directly to OO but then again what works
for one app, may hinder others... no ideal solution.
I suspect that things will stay as they are anyway... so your our app
lose on this one and will just have
Another significant thought... could you 'please' consider changing
the name of the user node INSIDE the retweeted_status node to say
retweeted_user ?
Thius will make JSON parsing way simpler... especially if the goal is
to extract the retweeted_status when present; or do things like
quickly
No, please don't change that to retweeted_user ... the data structure
included as the retweeted status is a status, and that data structure has a
user property. That's a very clear object model, and should map very well to
JSON, as it's nested, not at the same level as the main user the retweet is
Hey John,
Thanks for that... can you put an earliest date on 'very soon' please
- just so I know how long we've got?
Thanks
Simon (Zaudio)
On Oct 3, 8:15 pm, John Kalucki jkalu...@gmail.com wrote:
There are plans to filter retweets from various resource, see the
documentation. However, it
This sounds a lot more sensible...
Importantly, where can we expect this new payload to be returned...
any of the following methods as well?
REST API
statuses/mentions
statuses/user
Streaming API/Shadow
I need to know in advance of such an addition to any of these, as
otherwise the parser on
I am a bit confused as to how we can use these new APIs.
If I use the new retreet API in my app then no-one will see it if they
are using any app that isnt using the new home_timeline (perhaps no-
one) ... so how can it ever be used unless everyone (I mean client
apps and sites) uses the new
All apps will eventually have to use home_timeline as the platform
guys have said they will remove the old timeline in a matter of months
after the retweet api launches
On Oct 2, 8:08 am, Coderanger d...@coderanger.com wrote:
I am a bit confused as to how we can use these new APIs.
If I use
So you have to wait until then before you can even support the retweet
posting?
Not at all, just that retweets won't show in any app using the new re-
tweet API.
However I expect many apps that care about their users will switch
because retweets from the biggest source i.e. web will be using it!
On Oct 2, 11:45 am, Coderanger d...@coderanger.com wrote:
So you have to wait
A final question, will home_timeline also follow this same format, as
the docs still have the old format.
On Oct 1, 6:46 am, Rich rhyl...@gmail.com wrote:
One question though I notice you're adding the RT @user at the
beginning, is this intentional or can we add it ourselves (as some
people
Hi,
first of all, let me say that I think this change to the relation between
the retweet and the retweeted status makes much sense - it feels much more
natural to see it as user A retweets user B instead of user B retweeted
by user A, especially if you don't follow B.
A couple of questions
Great, I think this is much better and provides a better way of
identify which tweet is a retweet and which is not.
/Amitab
Follow Twalle @mytwaller
On Sep 30, 4:08 pm, Marcel Molina mar...@twitter.com wrote:
We've updated the retweet payload to look a lot more like a regular
tweet's
Marcel Molina wrote:
The above payloads don't contain a retweet_count element yet and
they probably will. Other than that we don't suspect any more major
changes as we approach a full public launch. As always, though, we're
open and solicitous of everyone's feedback.
This is a great
I don't like this approach purely based on the fact it's no longer
backwards compatible, it's going to break a lot of clients who aren't
looking for a retweet_status tag.
On Oct 1, 2:57 am, Brian Smith br...@briansmith.org wrote:
Marcel Molina wrote:
The above payloads don't contain a
Sorry ignore me, lack of sleep and I missed the text tag outside the
retweet_status one!
On Oct 1, 2:57 am, Brian Smith br...@briansmith.org wrote:
Marcel Molina wrote:
The above payloads don't contain a retweet_count element yet and
they probably will. Other than that we don't suspect any
One question though I notice you're adding the RT @user at the
beginning, is this intentional or can we add it ourselves (as some
people prefer the RT message (via @user) format)
On Oct 1, 6:44 am, Rich rhyl...@gmail.com wrote:
Sorry ignore me, lack of sleep and I missed the text tag outside
18 matches
Mail list logo
