Matt,
Thanks for the --no-ssl trick, much appreciated! That was staring me right
in the face with the --help output and I still managed not to see it.
No worries, I'm only trying to use twurl for a test. We do use twitter4j
for live firehose access.
Thanks,
Dan
On Sun, Dec 26, 2010 at 10:54 A
0, or otherwise. The team responsible for the low
> level component causing the bug has a fix planned, but it can't be applied
> until a few more dependencies are resolved.
>
> Thanks,
> Taylor
>
> On Wed, Dec 22, 2010 at 2:59 PM, Dan Checkoway wrote:
>
>> I just w
know what the listed count is"? What
happens if/when -4 starts popping out?
I realize this is pretty low priority, but it's still a bug...
Thanks,
Dan
On Fri, Dec 17, 2010 at 7:17 AM, Dan Checkoway wrote:
> Check this out...today sometime between 4:01:43 AM PST and 4:01:53 AM PS
; As Tom suggested, run through the Streaming Documentation linked to from
> http://dev.twitter.com/pages/streaming_api and make sure you implement the
> suggestions.
>
> Best,
> @themattharris
> Developer Advocate, Twitter
> http://twitter.com/themattharris
>
>
> O
Our app is using twitter4j 2.1.9-SNAPSHOT against the twitter firehose, and
lately we are having problems with the stream "just ending" out of the
blue. It happens several times a day lately with no rhyme or reason.
Here's an example of what we see:
Stream closed.TwitterException{exceptionCode=[a
his is being looked into. I'll update when I have news.
>
> Taylor
>
> On Tuesday, December 14, 2010, Dan Checkoway wrote:
> > Yeah, you bet. Twitter4j isn't logging a timestamp when it happens, but
> here are a handful of timestamps for unrelated stuff that got l
> Hi Dan,
>
> Do you continue to see events like this happening? Can you provide a
> recent example in as-provided JSON or XML?
>
> Thanks,
> Taylor
>
> On Tue, Dec 14, 2010 at 2:13 PM, Dan Checkoway
> wrote:
> > Anybody else seeing user.listed_count occasionally c
time an event like this happened?
>
> Taylor
>
> On Tue, Dec 14, 2010 at 3:41 PM, Dan Checkoway
> wrote:
> > I know this is the weenie answer, but I haven't been able to track a
> > specific offending JSON object down yet, since it only seems to happen on
> >
Anybody else seeing user.listed_count occasionally coming back as
4294967295? That value just happens to equate to: 1 + (2 *
Integer.MAX_VALUE) Sure looks like an unsigned version of -1 to me...
Anyway, it's breaking twitter4j.TwitterStream stuff. I've mentioned that
separately on the twitter4
I'm also patiently awaiting a response from twitter about this. Are the ids
sane for 64-bit *signed* long?
Dan
On Mon, Oct 18, 2010 at 9:08 PM, jon wrote:
> Hi,
>
> You wrote that the IDs are "unsigned" 64 bit ints, but the IdWorker is
> pumping out java Longs which are signed. I'm assuming t
+1 on needing this fix. Sorry for the duplicate report of this issue I
slapped in another thread this morning.
Thanks,
Dan
On Sat, Apr 17, 2010 at 12:04 PM, Mark McBride wrote:
> Yes. A fix has been identified, and should be deployed in a few days
>
> Sent from mobile device
>
>
> On Apr 17,
re if that's a related issue, or an intentional thing that has also
affected the API, or what.
Anyway, can twitter please fix paging on the "GET list memberships" API?
Thanks,
Dan Checkoway
--
Subscription settings:
http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Dean,
Basic auth sends the password essentially in the clear (encoded, but
trivially so). It's really in everybody's best interest NOT to use basic
auth, but to switch to something less sniffable/repeatable.
For example, here's a sample "credential" you're passing to twitter (HTTP
header) when y
13 matches
Mail list logo