Thanks Matt!
What will happen with the lost data period?
Can we have at least a part of that sent our way or are just left with
a blank period?
On Nov 12, 3:10 pm, Matt Sanford [EMAIL PROTECTED] wrote:
Hi Jungle,
It's a problem in the back-end system and we're working on it right
now.
On Wed, Nov 12, 2008 at 3:37 AM, Waitman Gobble [EMAIL PROTECTED] wrote:
Hi,
I'm doing like a hundred get searches an hour, and some post
requests. I thought I read somewhere that I should only do 60 requests
per hour or I'd be thrashed. I also thought I read somewhere that I
could request
Thanks James. But for this i need to look into the Twitter account
constantly right! I have to write a loop which is running all the time and
looking for the Twitter users account for the updates. If this is the case,
i was wondering will it be a problem for the application performance.
Thanks,
Thank you Damon
Alright, we've filed this bug, although it's not specific to the API. Thanks!
On Mon, Nov 10, 2008 at 3:59 PM, OK [EMAIL PROTECTED] wrote:
Alex, per your standards, they are not appearing in the correct order.
(When it was marked as a favorite.)
The following are the most recent favorites I
http://code.google.com/p/twitter-api/issues/detail?id=2
On Tue, Nov 11, 2008 at 19:22, Amir Michail [EMAIL PROTECTED] wrote:
Hi,
With the google app engine, users don't give you their google password
-- the log in is handled by google.
Could something like that be done with twitter so
I would like to retrieve basic profile data on a protected user. The
best API method for such a request seems to be /users/show [1] for
extended information of a given user yet Twitter returns a 403 for
such a request.
I would like to be able to display the same level of data present on
the
Thanks Niall for bringing this up and Alex for the quick response! I have
the same issue and would love to see this get implemented!
On Wed, Nov 12, 2008 at 12:11 PM, Alex Payne [EMAIL PROTECTED] wrote:
Yes, that makes perfect sense. That's how we handle protected users
in other responses:
Right now those modifier parameters are a bit of a mess, and may or
may not work in tandem. Pick one or the other in the meantime, or
request the whole thing and filter client-side. Our caching is such
that getting the entire response shouldn't be that slow, although I'd
understand wanting to
Apologies, but in the current system there's not a great way to
recover data. We're working on that.
On Wed, Nov 12, 2008 at 9:16 AM, jungle [EMAIL PROTECTED] wrote:
Thanks Matt!
What will happen with the lost data period?
Can we have at least a part of that sent our way or are just left
Hi,
With the google app engine, users don't give you their google password
-- the log in is handled by google.
Could something like that be done with twitter so that users don't
need to trust you with their twitter password?
Amir
Filed as issue 151.
http://code.google.com/p/twitter-api/issues/detail?id=151
-Niall Kennedy
On Nov 12, 12:11 pm, Alex Payne [EMAIL PROTECTED] wrote:
Yes, that makes perfect sense. That's how we handle protected users
in other responses: we omit their current status. Please file an
issue
Just fixed a crasher in Blogo due to the ID being missing from some of
the results in the atom feed. Is this a known issue? Thanks,
Ben
Thanks, Alex. As long as you have the bug filed, I would like to see
favorites appear in chronological order in the time they were
tweeted. If I star a hotdogsladies tweet from last July, and a bunch
of tweets from today, I'd prefer the the hotdogsladies tweet were
filed in chronological order
Now to just get follower/following in chronological order from date
followed (or simply a since variable - either/or is fine). It's
been over a year since it was originally brought up?
On Nov 12, 2008, at 2:18 PM, OK wrote:
Thanks, Alex. As long as you have the bug filed, I would like
That would explain it then. Now I need to figure out why at times
some users stop following even though I call follow in the API. Let
me track it down and I'll update if it looks like a problem.
Jesse
On Nov 12, 2008, at 3:59 PM, Matt Sanford wrote:
Hi Jesse,
The follow method is
I'm still noticing suspended accounts showing up in follower data. Of
course, you can detect them by checking the error message returned,
but this is wasting near at least 5 minutes for each user in the
script I'm running. Is there a way you can exclude those from the
list of
Yeah, I've wanted this just with my regular Twitter account. They
don't automatically remove suspended accounts from follower lists, but
I too wish they would.
-damon
On Wed, Nov 12, 2008 at 5:42 PM, Jesse Stay [EMAIL PROTECTED] wrote:
I'm still noticing suspended accounts showing up in
I just noticed something shouldn't the
Content-Type: application/x-www-form-urlencoded
This could be the problem.
HTTP 500 Error usually means its a server error and its not your
fault, however it may have something to do with your status post data.
If you could, post the return headers and/or body. Also, it may have
just been a simple problem with Twitter at the time.
I just tested the API and it works fine
Instead of removing them, you should just add a field like 'status'
or something similar.
You cannot, sorry. However, you can keep track of Twitter's progress
on OAuth. This method would not require any passwords.
A query parameter enabling me to not return the suspendeds would be
ideal if you do that. The problem with just a 'status' for each
follower is I still get all the suspended accounts returned in the
follower data, taking longer to query all their friends. This can be
anywhere near 50
Thank you very much and i would like to have it please.
On Thu, Nov 13, 2008 at 9:20 AM, fastest963 [EMAIL PROTECTED] wrote:
You can try GNIP, however I haven't used them before.
Yes you should probably loop every 3-5 (maybe more, depending on how
accurate you want to be) minutes or so
24 matches
Mail list logo