[twitter-dev] Re: Handling the OAuth flow when the user clicks Deny / Decline

[MichaelBailey]

You are kidding me? Is my message above reason to Ban me from this
group?

On May 6, 4:41 pm, Mobasoft  wrote:
> Glad that you are finally getting around to this.
> I posted it April 
> 10thhttp://groups.google.com/group/twitter-development-talk/browse_thread...
>
> On May 6, 10:28 am, jmathai  wrote:
>
> > That would work.  So would something a a bit simpler.
>
> > I am not sure I see the need for the username to be passed back.
> > Seems like that could easily be done by the site.  Also unsure as to
> > why the special key is needed if it's always just returned as a
> > parameter.
>
> > Is this something that can be specified in the OAuth specs?  Would be
> > nice to have a standard way to handle this very valid OAuth flow.
>
> > On May 5, 10:36 am, Doug Williams  wrote:
>
> > > I'm trying to decide if this could easily be part of [1]? Any objections 
> > > for
> > > these to be one in the same?
>
> > > 1.http://code.google.com/p/twitter-api/issues/detail?id=545
>
> > > Thanks,
> > > Doug
> > > --
>
> > > Doug Williams
> > > Twitter Platform Supporthttp://twitter.com/dougw
>
> > > On Tue, May 5, 2009 at 8:27 AM, jmathai  wrote:
>
> > > > When the user clicks decline the flow is abruptly disrupted.  I didn't
> > > > see anything in the OAuth spec that specifies how a "decline" is
> > > > handled.
>
> > > > It would be nice if there was a "decline" url that the application
> > > > could specify which the user is redirected to.

[twitter-dev] Re: Handling the OAuth flow when the user clicks Deny / Decline

[Cameron Kaiser]

> You are kidding me? Is my message above reason to Ban me from this
> group?

I can only conclude this was a mistaken click on somebody's part, so I have
temporarily removed the ban. We'll deal with it off list.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Art is anything you can get away with. -- Marshall McLuhan -

[twitter-dev] Re: Handling the OAuth flow when the user clicks Deny / Decline

[MobaTalk]

many thanks - it happens, I guess.

On May 7, 7:38 am, Cameron Kaiser  wrote:
> > You are kidding me? Is my message above reason to Ban me from this
> > group?
>
> I can only conclude this was a mistaken click on somebody's part, so I have
> temporarily removed the ban. We'll deal with it off list.
>
> --
>  personal:http://www.cameronkaiser.com/--
>   Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com
> -- Art is anything you can get away with. -- Marshall McLuhan 
> -

[twitter-dev] Public Timeline Frozen

[mattarnold1977]

I just checked the log on my server and noticed that the public time
line has been putting out the same status information since around 5
o'clock yesterday.  Is this a known issue?

-Matt

[twitter-dev] Re: Default Device Notification

[Chris Carson]

Hi --

The follow parameter (turning device notifications on or off)  in
friendships/create is not behaving as I expected. It appears that
having the follow parameter in the post data turns device
notifications on, no matter what value you give it.  My (php) code was
this:

public function createFriendship($id = null, $user_id = null,
$screen_name = null, $follow = false){
  //code deleted for clarity
$params["follow"] = $follow;
return $this->makeAPIRequest("http://twitter.com/friendships/
create.json",$params,"POST","TwitterAPIUser");
}

Calling createFriendship(null, null, "chriscarson") would, after php
converts false into an empty string, result in post data like this...

screen_name=chriscarson&follow=

I expected the API to interpret the null "follow" value as false, but
I think it interprets the presence of "follow" as true, without
checking the value.

Anyway, I fixed by  doing this...

 if ($follow) $params["follow"] = $follow;

This results in post data ...

screen_name=chriscarson

This seems to be working.  But maybe it'd be a good idea to clarify
the expected values for boolean post parameters.  Thanks,

--Chris



On Apr 22, 8:36 pm, Eric Blair  wrote:
> Damn. That was it. Thanks for the pointer.
>
> --Eric
>
> On Apr 22, 2009, at 7:58 PM, Matt Sanford wrote:
>
>
>
> > Hi Eric,
>
> >    If you do a friendships/create?follow=true is will turn on  
> > notifications when the follower is added. Poorly namedparameter, I  
> > know.
>
> > — Matt
>
> > On Apr 22, 2009, at 04:31 PM, Eric Blair wrote:
>
> >> Is there any condition that would result in device notification  
> >> being active immediately after following somebody via friendship/
> >> create? I have a user who's telling me they're getting SMS updates  
> >> from new friends and following them in my app, but I don't see  
> >> anything in my logs indicating the I called /notifications/follow.
>
> >> I've looked through the API docs and the settings on Twitter and  
> >> nothing's jumped out at me.
>
> >> Thanks,
> >> --Eric

[twitter-dev] Re: Public Timeline Frozen

[Alan]

To give you an impression of the scale of this issue, of the last 10
requests for the feed, I have received 5 repeats each of 2 distinct
feeds:

The first begins with status 1718278475 , and is malformed, due to the
presence of an end-of-medium character in status 1718277608
The second begins with status 1718273418

Both statuses are from yesterday (6th May), although we are now 16
hours into the 7th of May.

The feeds were requested once per minute for 10 minutes, and repeats
are not consecutive, but rather interleaved, I also have many
instances of the same malformed (first) feed over the last 24 hours.
I don't have dumps of those feeds yesterday, but given that the xml
parser reports an invalid char at the same line/column, we can assume
that it's the same feed.

I have essentially received no new statuses since yesterday.

Hoping we can solve this issue soon.  Please contact me if you need
more data.  Many thanks,

Alan

On May 7, 3:01 pm, mattarnold1977  wrote:
> I just checked the log on my server and noticed that the public time
> line has been putting out the same status information since around 5
> o'clock yesterday.  Is this a known issue?
>
> -Matt

[twitter-dev] Re: Public Timeline Frozen

[Alan]

I've been seeing a ver similar issue since yesterday with the partner
feed - a very small number of feeds are repeating over and over,
including one containing malformed XML (which makes it nicely obvious,
as it shows up in error logs with an invalid character at the same
line/column each time).  The repeats are not necessarily consecutive,
are separated by minutes, hours even.

Please contact me if I can help by supplying more data.  Many thanks,

Alan

On May 7, 3:01 pm, mattarnold1977  wrote:
> I just checked the log on my server and noticed that the public time
> line has been putting out the same status information since around 5
> o'clock yesterday.  Is this a known issue?
>
> -Matt

[twitter-dev] Re: invalid xml char in public timeline

[Alan]

I'm seeing this same problem at the exact same line/column many, many
times per hour since yesterday.  This is also because the feeds we are
receiving (partner feed) are repeating constantly.  This is a separate
issue, whereby only a small handful of feeds are being repeated over
and over, and we get this malformed feed coming up about 30 times per
hour now (out of a total of 60 requests per hour).  The char, as
mentioned, is "end-of-medium", and the status that contains it is
1718277608 , the text is "RT @Gonendunit New Study: Americas ..." ,
the invalid char comes between the a and s in Americas.

If you need more info, I can easily extract more from my debug output.

Hoping we can get to the bottom of this. Many thanks,

Alan

On May 7, 5:24 am, AJ Chen  wrote:
> the example xml feed I'm looking at has status ID from 1718273418 to
> 1718264182
> -aj
>
> On May 6, 7:21 pm, Cameron Kaiser  wrote:
>
> > > I'm getting this xml parsing error all day long. I'm using jdom.jar
> > > and pass twitter api xml response directly to build jdom document.
> > > Looking at the xml file right now, but hope you can take at look at it
> > > as well. I expect other jdom users may see the same error.
>
> > > 2009-05-06 19:11:49,401 ERROR feed.XmlFetcher (XmlFetcher.java:run
> > > (136)) - failed to fetchhttp://twitter.com/statuses/public_timeline.xml;
> > > org.jdom.input.JDOMParseException: Error on line 8148: An invalid XML
> > > character (Unicode: 0x19) was found in the element content of the
> > > document.
>
> > The problem is that the view moves so fast that it's unlikely it's still
> > there. When you dump the raw data, what is the last status ID you see before
> > it bugs out?
>
> > --
> >  
> > personal:http://www.cameronkaiser.com/--
> >   Cameron Kaiser * Floodgap Systems *www.floodgap.com*ckai...@floodgap.com
> > -- It's the car, right? Chicks dig the car. -- "Batman Forever" 
> > ---

[twitter-dev] Re: Can Twitter please pick a From: and stick with it?

[Chad Etzel]

Hi Matt,

When you decide on the final format and deploy, will you let us know,
please?  I'm leaving my email filters in limbo until then.

Thanks,
-Chad

On Thu, May 7, 2009 at 12:59 AM, TjL  wrote:
>
> *sigh*
>
> Seriously? I've already started telling people to change their filters
> and now they're going to break *again*.
>
> This is why daddy drinks.
>
> All kidding aside, I don't understand how a change like this gets
> pushed out without the left hand knowing WTF the right hand is doing —
> which is what it looks like (from an outsider's perspective) happened.
>
> IMO/FWIW: You've gotten too big to make these sorts of changes without
> more consideration and communication. It makes me look bad as a
> developer, and it makes Twitter look bad.
>
> The irony is that you're a company built around communication.
>
> TjL
>
>
>
>
>
> On Wed, May 6, 2009 at 6:55 PM, Matt Sanford  wrote:
>>
>> Hi all,
>>
>>The change in from address was meant to fix the 'allow images' but in the
>> process broke some ISP spam filters, some spam reporting, and a great many
>> people's mail filters. We're working on rolling that back now. Sorry for the
>> disruption.
>>
>> Thanks;
>>  – Matt Sanford / @mzsanford
>> Twitter Dev
>>
>> On May 6, 2009, at 3:13 PM, TjL wrote:
>>
>>>
>>> FWIW I think "nore...@twitter.com" is the right choice, it's certainly
>>> a lot easier for image display, etc.
>>>
>>> But it sounds like John Adams thinks this is going to change back. I
>>> hope this will be clarified.
>>>
>>>
>>> On Wed, May 6, 2009 at 5:58 PM, Matt Sanford  wrote:

 Hi there,

   We had changed the from address to try and improve bounce reporting and
 prevent being marked as spam by major ISPs. When we added the HTML
 formatting we found that we needed a consistent address for the 'always
 display images' option in many clients so we changed things around again.
 Hopefully this will be the last change as it causes us a bunch of work as
 well. I'll keep an eye out for future changes and try and let people
 know.

 Thanks;
  – Matt Sanford / @mzsanford
Twitter Dev

 On May 6, 2009, at 2:53 PM, TjL wrote:

>
> The email notifications for new followers used to come from (From:)
>
> Twitter 
>
> then it changed to
>
> Twitter 
>
> then it changed to
>
> Twitter 
>
> again.
>
>
> Every time you do this, every single person using TwitReport has to
> change their filters, and I spend 2 weeks, at least, explaining to
> people why it stopped working, and some number of people probably
> assume that things are broken on my end and stop using it altogether.
>
> I'm not making a dime off of this project (nor do I want to), it's
> something that I'm doing to make Twitter a bit nicer to use, but
> having something as basic as this change twice and break the entire
> thing is a bit of a pain in the ass and a not-insignificant waste of
> time.
>
> So I hope that y'all will keep this one, since you've liked it enough
> to use it twice now :-)
>
>
> THAT SAID, I'm glad that the *format* of the notifications has
> improved. I certainly think that is the right way to go.
>
>
> - TjL


>>
>>
>

[twitter-dev] Re: Can Twitter please pick a From: and stick with it?

[Matt Sanford]

Hi all,

I left last night while they were rolling this back to the old  
long format addresses. Re-reading the logs this morning it seems like  
there was some sort of problem and it was rolled back. Waiting for the  
engineer in question so I can find out more details but based on what  
I'm seeing it looks like an unrelated problem. I expect the long-style  
addresses to be re-deployed with our first deploy today.


As far as poor communication: that's fair. I made this change  
after talking with the mail processing folks (ok, the guy) and product  
folks and I broke your filters. I'm sorry about that and when you  
brought it up I fixed the issue, wrote the tests, replied to the mails  
and begged the deploy engineer to make it an emergency. I tried to  
communicate things.


I should have told the list (and probably posted to  
blog.twitter.com) this user-facing email change was coming … surprise  
is overrated. I definitely should have thought more about how it would  
effect filtering. Totally my bad … you can send flaming sacks of dog  
poop to REDACTED.


Thanks;
 – Matt "Can do no right" Sanford

On May 7, 2009, at 8:15 AM, Chad Etzel wrote:



Hi Matt,

When you decide on the final format and deploy, will you let us know,
please?  I'm leaving my email filters in limbo until then.

Thanks,
-Chad

On Thu, May 7, 2009 at 12:59 AM, TjL  wrote:


*sigh*

Seriously? I've already started telling people to change their  
filters

and now they're going to break *again*.

This is why daddy drinks.

All kidding aside, I don't understand how a change like this gets
pushed out without the left hand knowing WTF the right hand is  
doing —
which is what it looks like (from an outsider's perspective)  
happened.


IMO/FWIW: You've gotten too big to make these sorts of changes  
without

more consideration and communication. It makes me look bad as a
developer, and it makes Twitter look bad.

The irony is that you're a company built around communication.

TjL





On Wed, May 6, 2009 at 6:55 PM, Matt Sanford   
wrote:


Hi all,

  The change in from address was meant to fix the 'allow images'  
but in the
process broke some ISP spam filters, some spam reporting, and a  
great many
people's mail filters. We're working on rolling that back now.  
Sorry for the

disruption.

Thanks;
– Matt Sanford / @mzsanford
   Twitter Dev

On May 6, 2009, at 3:13 PM, TjL wrote:



FWIW I think "nore...@twitter.com" is the right choice, it's  
certainly

a lot easier for image display, etc.

But it sounds like John Adams thinks this is going to change  
back. I

hope this will be clarified.


On Wed, May 6, 2009 at 5:58 PM, Matt Sanford   
wrote:


Hi there,

 We had changed the from address to try and improve bounce  
reporting and

prevent being marked as spam by major ISPs. When we added the HTML
formatting we found that we needed a consistent address for the  
'always
display images' option in many clients so we changed things  
around again.
Hopefully this will be the last change as it causes us a bunch  
of work as
well. I'll keep an eye out for future changes and try and let  
people

know.

Thanks;
– Matt Sanford / @mzsanford
  Twitter Dev

On May 6, 2009, at 2:53 PM, TjL wrote:



The email notifications for new followers used to come from  
(From:)


Twitter 

then it changed to

Twitter >


then it changed to

Twitter 

again.


Every time you do this, every single person using TwitReport  
has to
change their filters, and I spend 2 weeks, at least, explaining  
to

people why it stopped working, and some number of people probably
assume that things are broken on my end and stop using it  
altogether.


I'm not making a dime off of this project (nor do I want to),  
it's

something that I'm doing to make Twitter a bit nicer to use, but
having something as basic as this change twice and break the  
entire
thing is a bit of a pain in the ass and a not-insignificant  
waste of

time.

So I hope that y'all will keep this one, since you've liked it  
enough

to use it twice now :-)


THAT SAID, I'm glad that the *format* of the notifications has
improved. I certainly think that is the right way to go.


- TjL

[twitter-dev] Sample code to automate the basic to oauth credentials exchange

[jon]

Hi,

We recently converted our site to use twitter oauth over basic
authentication and automated the exchange of credentials so that we
didn't have to keep multiple workflows around nor bother our users.

Here's a helpful script in ruby which makes use of the great twitter
and mechanize gems.
(this is obviously a little bit brittle, so I wouldn't rely on it for
anything other than batch conversion)

Also, the script makes multiple http calls to twitter and is subject
to timeouts, backhoes, and other ill effects, so expect it to be slow
and fail often.  We loaded up pending conversions into a persistent
transactional queue and ran multiple processes in parallel.

http://gist.github.com/108144

- Jon

[twitter-dev] Re: Can Twitter please pick a From: and stick with it?

[Ed Finkler]

You do a ton of great things, Matt. We all make mistakes, but you and
the rest of the crew there do a bang-up job.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com


On May 7, 11:24 am, Matt Sanford  wrote:
> Hi all,
>
>      I left last night while they were rolling this back to the old  
> long format addresses. Re-reading the logs this morning it seems like  
> there was some sort of problem and it was rolled back. Waiting for the  
> engineer in question so I can find out more details but based on what  
> I'm seeing it looks like an unrelated problem. I expect the long-style  
> addresses to be re-deployed with our first deploy today.
>
>      As far as poor communication: that's fair. I made this change  
> after talking with the mail processing folks (ok, the guy) and product  
> folks and I broke your filters. I'm sorry about that and when you  
> brought it up I fixed the issue, wrote the tests, replied to the mails  
> and begged the deploy engineer to make it an emergency. I tried to  
> communicate things.
>
>      I should have told the list (and probably posted to  
> blog.twitter.com) this user-facing email change was coming … surprise  
> is overrated. I definitely should have thought more about how it would  
> effect filtering. Totally my bad … you can send flaming sacks of dog  
> poop to REDACTED.
>
> Thanks;
>   – Matt "Can do no right" Sanford
>
> On May 7, 2009, at 8:15 AM, Chad Etzel wrote:
>
>
>
> > Hi Matt,
>
> > When you decide on the final format and deploy, will you let us know,
> > please?  I'm leaving my email filters in limbo until then.
>
> > Thanks,
> > -Chad
>
> > On Thu, May 7, 2009 at 12:59 AM, TjL  wrote:
>
> >> *sigh*
>
> >> Seriously? I've already started telling people to change their  
> >> filters
> >> and now they're going to break *again*.
>
> >> This is why daddy drinks.
>
> >> All kidding aside, I don't understand how a change like this gets
> >> pushed out without the left hand knowing WTF the right hand is  
> >> doing —
> >> which is what it looks like (from an outsider's perspective)  
> >> happened.
>
> >> IMO/FWIW: You've gotten too big to make these sorts of changes  
> >> without
> >> more consideration and communication. It makes me look bad as a
> >> developer, and it makes Twitter look bad.
>
> >> The irony is that you're a company built around communication.
>
> >> TjL
>
> >> On Wed, May 6, 2009 at 6:55 PM, Matt Sanford   
> >> wrote:
>
> >>> Hi all,
>
> >>>   The change in from address was meant to fix the 'allow images'  
> >>> but in the
> >>> process broke some ISP spam filters, some spam reporting, and a  
> >>> great many
> >>> people's mail filters. We're working on rolling that back now.  
> >>> Sorry for the
> >>> disruption.
>
> >>> Thanks;
> >>> – Matt Sanford / @mzsanford
> >>>    Twitter Dev
>
> >>> On May 6, 2009, at 3:13 PM, TjL wrote:
>
>  FWIW I think "nore...@twitter.com" is the right choice, it's  
>  certainly
>  a lot easier for image display, etc.
>
>  But it sounds like John Adams thinks this is going to change  
>  back. I
>  hope this will be clarified.
>
>  On Wed, May 6, 2009 at 5:58 PM, Matt Sanford   
>  wrote:
>
> > Hi there,
>
> >  We had changed the from address to try and improve bounce  
> > reporting and
> > prevent being marked as spam by major ISPs. When we added the HTML
> > formatting we found that we needed a consistent address for the  
> > 'always
> > display images' option in many clients so we changed things  
> > around again.
> > Hopefully this will be the last change as it causes us a bunch  
> > of work as
> > well. I'll keep an eye out for future changes and try and let  
> > people
> > know.
>
> > Thanks;
> > – Matt Sanford / @mzsanford
> >   Twitter Dev
>
> > On May 6, 2009, at 2:53 PM, TjL wrote:
>
> >> The email notifications for new followers used to come from  
> >> (From:)
>
> >> Twitter 
>
> >> then it changed to
>
> >> Twitter 
> >> then it changed to
>
> >> Twitter 
>
> >> again.
>
> >> Every time you do this, every single person using TwitReport  
> >> has to
> >> change their filters, and I spend 2 weeks, at least, explaining  
> >> to
> >> people why it stopped working, and some number of people probably
> >> assume that things are broken on my end and stop using it  
> >> altogether.
>
> >> I'm not making a dime off of this project (nor do I want to),  
> >> it's
> >> something that I'm doing to make Twitter a bit nicer to use, but
> >> having something as basic as this change twice and break the  
> >> entire
> >> thing is a bit of a pain in the ass and a not-insignificant  
> >> waste of
> >> time.
>
> >> So I hope that y'all will keep this one, since you've liked it  
> >> enough
> >> to use it twice now :-)
>
> >> THAT 

[twitter-dev] Re: Public Timeline Frozen

[Doug Williams]

We're having a look. I'll update this thread when it is taken care of.

Thanks,
Doug
--

Doug Williams
Twitter Platform Support
http://twitter.com/dougw




On Thu, May 7, 2009 at 7:19 AM, Alan  wrote:

>
> I've been seeing a ver similar issue since yesterday with the partner
> feed - a very small number of feeds are repeating over and over,
> including one containing malformed XML (which makes it nicely obvious,
> as it shows up in error logs with an invalid character at the same
> line/column each time).  The repeats are not necessarily consecutive,
> are separated by minutes, hours even.
>
> Please contact me if I can help by supplying more data.  Many thanks,
>
> Alan
>
> On May 7, 3:01 pm, mattarnold1977  wrote:
> > I just checked the log on my server and noticed that the public time
> > line has been putting out the same status information since around 5
> > o'clock yesterday.  Is this a known issue?
> >
> > -Matt
>

[twitter-dev] Re: Public Timeline Frozen

[John Kalucki]

Matt,

As Doug mentioned, we're working on fixing the public timeline. I hope
we can get that updating again shortly.

As a workaround, you might consider an early migration to the
Streaming API. The /spritzer resource should have about the same
amount of data, but in an easier to consume format. So far the
availability has been very good, and the latency very low.

-John


On May 7, 6:01 am, mattarnold1977  wrote:
> I just checked the log on my server and noticed that the public time
> line has been putting out the same status information since around 5
> o'clock yesterday.  Is this a known issue?
>
> -Matt

[twitter-dev] Re: Default Device Notification

[Doug Williams]

Chris,
I'll clarify that now.

Thanks,
Doug
--

Doug Williams
Twitter Platform Support
http://twitter.com/dougw




On Thu, May 7, 2009 at 6:31 AM, Chris Carson wrote:

>
> Hi --
>
> The follow parameter (turning device notifications on or off)  in
> friendships/create is not behaving as I expected. It appears that
> having the follow parameter in the post data turns device
> notifications on, no matter what value you give it.  My (php) code was
> this:
>
> public function createFriendship($id = null, $user_id = null,
> $screen_name = null, $follow = false){
>  //code deleted for clarity
>$params["follow"] = $follow;
>return $this->makeAPIRequest("http://twitter.com/friendships/
> create.json",$params,"POST","TwitterAPIUser");
> }
>
> Calling createFriendship(null, null, "chriscarson") would, after php
> converts false into an empty string, result in post data like this...
>
> screen_name=chriscarson&follow=
>
> I expected the API to interpret the null "follow" value as false, but
> I think it interprets the presence of "follow" as true, without
> checking the value.
>
> Anyway, I fixed by  doing this...
>
>  if ($follow) $params["follow"] = $follow;
>
> This results in post data ...
>
> screen_name=chriscarson
>
> This seems to be working.  But maybe it'd be a good idea to clarify
> the expected values for boolean post parameters.  Thanks,
>
> --Chris
>
>
>
> On Apr 22, 8:36 pm, Eric Blair  wrote:
> > Damn. That was it. Thanks for the pointer.
> >
> > --Eric
> >
> > On Apr 22, 2009, at 7:58 PM, Matt Sanford wrote:
> >
> >
> >
> > > Hi Eric,
> >
> > >If you do a friendships/create?follow=true is will turn on
> > > notifications when the follower is added. Poorly namedparameter, I
> > > know.
> >
> > > — Matt
> >
> > > On Apr 22, 2009, at 04:31 PM, Eric Blair wrote:
> >
> > >> Is there any condition that would result in device notification
> > >> being active immediately after following somebody via friendship/
> > >> create? I have a user who's telling me they're getting SMS updates
> > >> from new friends and following them in my app, but I don't see
> > >> anything in my logs indicating the I called /notifications/follow.
> >
> > >> I've looked through the API docs and the settings on Twitter and
> > >> nothing's jumped out at me.
> >
> > >> Thanks,
> > >> --Eric
>

[twitter-dev] Re: Public Timeline Frozen

[Hwee-Boon Yar]

Hmm.. when did the Streaming API come about? I see Firehose mentioned
in there, OK that's known. What's Spritzer? (I read the description
and tested it).

-
Hwee-Boon

On May 8, 12:39 am, John Kalucki  wrote:
> Matt,
>
> As Doug mentioned, we're working on fixing the public timeline. I hope
> we can get that updating again shortly.
>
> As a workaround, you might consider an early migration to the
> Streaming API. The /spritzer resource should have about the same
> amount of data, but in an easier to consume format. So far the
> availability has been very good, and the latency very low.
>
> -John
>
> On May 7, 6:01 am, mattarnold1977  wrote:
>
>
>
> > I just checked the log on my server and noticed that the public time
> > line has been putting out the same status information since around 5
> > o'clock yesterday.  Is this a known issue?
>
> > -Matt

[twitter-dev] Re: Public Timeline Frozen

[Doug Williams]

The public_timeline is updating correctly again.

@Hwee-Boon: that email as a bit premature. We will announce via @twitterapi
and this list when the push feed is available to the world at large.

Thanks,
Doug


Doug Williams | Platform Support | Twitter, Inc.

539 Bryant St. Suite 402, San Francisco, CA 94107 http://twitter.com/dougw



On Thu, May 7, 2009 at 10:16 AM, Hwee-Boon Yar  wrote:

>
> Hmm.. when did the Streaming API come about? I see Firehose mentioned
> in there, OK that's known. What's Spritzer? (I read the description
> and tested it).
>
> -
> Hwee-Boon
>
> On May 8, 12:39 am, John Kalucki  wrote:
> > Matt,
> >
> > As Doug mentioned, we're working on fixing the public timeline. I hope
> > we can get that updating again shortly.
> >
> > As a workaround, you might consider an early migration to the
> > Streaming API. The /spritzer resource should have about the same
> > amount of data, but in an easier to consume format. So far the
> > availability has been very good, and the latency very low.
> >
> > -John
> >
> > On May 7, 6:01 am, mattarnold1977  wrote:
> >
> >
> >
> > > I just checked the log on my server and noticed that the public time
> > > line has been putting out the same status information since around 5
> > > o'clock yesterday.  Is this a known issue?
> >
> > > -Matt
>

[twitter-dev] Re: Public Timeline Frozen

[Sanjay]

I'm not entirely sure but this may be somewhat my "fault".  Yesterday
I noticed two different tweets in the public timeline that were
attached to protected accounts.  I don't think they were an effect of
the accounts going from public->private since I caught them right
after they showed up and saw the accounts were protected.  I emailed
Twitter at 4:36pm and then another one at 5:16pm (EST).  That *may* be
the reason.

That said, I'm glad I'm not the only one noticing that the public
timeline was frozen.  I thought I was crazy for a while yesterday and
then started looking at other options (none of which have worked out
that well).

Sanjay

[twitter-dev] Re: Public Timeline Frozen

[Josh Roesslein]

I noticed the freeze on one of my scripts that monitors it yesterday.
Glad the issue has been resolved, everything working good here.

On Thu, May 7, 2009 at 11:04 AM, Sanjay  wrote:

>
> I'm not entirely sure but this may be somewhat my "fault".  Yesterday
> I noticed two different tweets in the public timeline that were
> attached to protected accounts.  I don't think they were an effect of
> the accounts going from public->private since I caught them right
> after they showed up and saw the accounts were protected.  I emailed
> Twitter at 4:36pm and then another one at 5:16pm (EST).  That *may* be
> the reason.
>
> That said, I'm glad I'm not the only one noticing that the public
> timeline was frozen.  I thought I was crazy for a while yesterday and
> then started looking at other options (none of which have worked out
> that well).
>
> Sanjay
>

[twitter-dev] Re: Public Timeline Frozen

[Alan]

Excellent job!

Many thanks,

Alan

On May 7, 9:38 pm, Doug Williams  wrote:
> The public_timeline is updating correctly again.
>
> @Hwee-Boon: that email as a bit premature. We will announce via @twitterapi
> and this list when the push feed is available to the world at large.
>
> Thanks,
> Doug
>
> 
> Doug Williams | Platform Support | Twitter, Inc.
>
> 539 Bryant St. Suite 402, San Francisco, CA 94107http://twitter.com/dougw
>
> On Thu, May 7, 2009 at 10:16 AM, Hwee-Boon Yar  wrote:
>
> > Hmm.. when did the Streaming API come about? I see Firehose mentioned
> > in there, OK that's known. What's Spritzer? (I read the description
> > and tested it).
>
> > -
> > Hwee-Boon
>
> > On May 8, 12:39 am, John Kalucki  wrote:
> > > Matt,
>
> > > As Doug mentioned, we're working on fixing the public timeline. I hope
> > > we can get that updating again shortly.
>
> > > As a workaround, you might consider an early migration to the
> > > Streaming API. The /spritzer resource should have about the same
> > > amount of data, but in an easier to consume format. So far the
> > > availability has been very good, and the latency very low.
>
> > > -John
>
> > > On May 7, 6:01 am, mattarnold1977  wrote:
>
> > > > I just checked the log on my server and noticed that the public time
> > > > line has been putting out the same status information since around 5
> > > > o'clock yesterday.  Is this a known issue?
>
> > > > -Matt

[twitter-dev] Re: Can Twitter please pick a From: and stick with it?

[Nick Arnett]

On Thu, May 7, 2009 at 8:15 AM, Chad Etzel  wrote:

>
> Hi Matt,
>
> When you decide on the final format and deploy, will you let us know,
> please?  I'm leaving my email filters in limbo until then.


I've dealt with this by leaving my old filters in place.  If Twitter
switches back to something older, I'm covered.

Nick

[twitter-dev] since_id basic usage confusion

[Joel Hughes]

Hi all,
I have looked at the API and searched this group but can't find the
answer.

I've created some code which is doing a search and doing some analysis
on the results and then poking the results into a database. Simple
enough.

This code then runs a few minutes later.

I obviously don't want to process the same tweets again so I'm
assuming that I need to use the "since_id" to help me out here and to
filter out previously seen tweets.

With simplexml in php I get this kinda XML back
tag:search.twitter.com,2005:1730670929

..so at the end of my process run I'm parsing out that number on the
end as that seems like the status_id to me

I then store that in the database and to feed it back into the process
when it NEXT runs

.the issue is though

If I run the process a couple of times on a row I can still see the
same tweets coming back - this foxes me as I would have thought that
by using status_id in this way I was effectively creating some sort of
"sliding window" where I could NOT see tweets older than this previous
id.

Is this assumption right (and, therefore, I'm looking at a code issue
here) or have I misunderstood the nature of status_id?

Thanks for any help/thoughts you can provide

Joel

[twitter-dev] always non-empty?

[Justin Hart]

This is an older post, but I saw no activity around it.  I'm seeing
this too.  It seems that the field profile_background_image_url should
either be blank or there should be another flag (like the tile flag)
that says if the background_image is being shown or not.

Thanks.

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/0053c1c03493bf8e/a861485dad3d85de#a861485dad3d85de
On Jan 20, 4:22 pm, Saša Šarunić  wrote:
> I'm not sure if this is expected behavior, but it seams like a bug to
> me:
>
> Even if I turn off abackgroundimagein my settings, it is still
> returned in call to /users/show api function.
>
> For example, I get this:
>   ...
>   
>  http://static.twitter.com/images/themes/theme1/bg.gif
>   
>   ...
>
> although I would expect to see something like this:
>   ...
>   
>   ...
>
> Can someone comment on this?
>
> Sasa S.www.shoutem.com

[twitter-dev] Re: since_id basic usage confusion

[Chad Etzel]

Your understanding of since_id is correct.  If you specify since_id=x
then you should only get back tweet ids strictly greater than x.  Are
you using PHP 5?  If so, I strongly recommend using the .json feed
instead of .atom and using json_decode() to parse the data.

-Chad

On Thu, May 7, 2009 at 5:37 PM, Joel Hughes  wrote:
>
> Hi all,
> I have looked at the API and searched this group but can't find the
> answer.
>
> I've created some code which is doing a search and doing some analysis
> on the results and then poking the results into a database. Simple
> enough.
>
> This code then runs a few minutes later.
>
> I obviously don't want to process the same tweets again so I'm
> assuming that I need to use the "since_id" to help me out here and to
> filter out previously seen tweets.
>
> With simplexml in php I get this kinda XML back
> tag:search.twitter.com,2005:1730670929
>
> ..so at the end of my process run I'm parsing out that number on the
> end as that seems like the status_id to me
>
> I then store that in the database and to feed it back into the process
> when it NEXT runs
>
> .the issue is though
>
> If I run the process a couple of times on a row I can still see the
> same tweets coming back - this foxes me as I would have thought that
> by using status_id in this way I was effectively creating some sort of
> "sliding window" where I could NOT see tweets older than this previous
> id.
>
> Is this assumption right (and, therefore, I'm looking at a code issue
> here) or have I misunderstood the nature of status_id?
>
> Thanks for any help/thoughts you can provide
>
> Joel
>
>

[twitter-dev] Planned site maintenance Friday, May 8th 2PM-3PM PST and Monday, May 11th Noon-1PM PST

[Doug Williams]

Prepare your apps! The status blog has the details [1]:

> We’re planning a significant database upgrade that will greatly increase
> system performance. To do this, we will require two planned maintenance
> windows: Friday, May 8th from 2p-3p Pacific and again on Monday, May 11th
> from Noon-1p Pacific.
>
> We’re taking these maintenance windows earlier in the day because of the
> extent of the changes involved. We want to make sure that we are able to
> respond quickly and efficiently to any issues that may arise from the work
> being performed.
>
> We will update [status.twitter.com] with any changes or additional
> information about this upgrade.
>
http://status.twitter.com/post/104738920/planned-maintenance-tomorrow-monday

Thanks,
Doug
--

Doug Williams
Twitter Platform Support
http://twitter.com/dougw

[twitter-dev] Re: since_id basic usage confusion

[Matt Sanford]

Hi there,

Just as a general software comment if you're sending since_id  
it's probably a good idea to also double check your results. That  
said: since_id should work like you expect. One case where it does not  
work is if you follow the next_page URL for pagination. When you do  
that there will be  warning message that the since_id has been  
removed. Are you going beyond page one be chance?


Thanks;
 – Matt Sanford / @mzsanford
 Twitter Dev

On May 7, 2009, at 3:14 PM, Chad Etzel wrote:



Your understanding of since_id is correct.  If you specify since_id=x
then you should only get back tweet ids strictly greater than x.  Are
you using PHP 5?  If so, I strongly recommend using the .json feed
instead of .atom and using json_decode() to parse the data.

-Chad

On Thu, May 7, 2009 at 5:37 PM, Joel Hughes   
wrote:


Hi all,
I have looked at the API and searched this group but can't find the
answer.

I've created some code which is doing a search and doing some  
analysis

on the results and then poking the results into a database. Simple
enough.

This code then runs a few minutes later.

I obviously don't want to process the same tweets again so I'm
assuming that I need to use the "since_id" to help me out here and to
filter out previously seen tweets.

With simplexml in php I get this kinda XML back
tag:search.twitter.com,2005:1730670929

..so at the end of my process run I'm parsing out that number on the
end as that seems like the status_id to me

I then store that in the database and to feed it back into the  
process

when it NEXT runs

.the issue is though

If I run the process a couple of times on a row I can still see the
same tweets coming back - this foxes me as I would have thought that
by using status_id in this way I was effectively creating some sort  
of
"sliding window" where I could NOT see tweets older than this  
previous

id.

Is this assumption right (and, therefore, I'm looking at a code issue
here) or have I misunderstood the nature of status_id?

Thanks for any help/thoughts you can provide

Joel

[twitter-dev] Re: Planned site maintenance Friday, May 8th 2PM-3PM PST and Monday, May 11th Noon-1PM PST

[Jesse Stay]

Can you share what exactly this will affect?  What symptoms will we see?

Thanks,

Jesse

On Thu, May 7, 2009 at 4:21 PM, Doug Williams  wrote:

> Prepare your apps! The status blog has the details [1]:
>
>> We’re planning a significant database upgrade that will greatly increase
>> system performance. To do this, we will require two planned maintenance
>> windows: Friday, May 8th from 2p-3p Pacific and again on Monday, May 11th
>> from Noon-1p Pacific.
>>
>> We’re taking these maintenance windows earlier in the day because of the
>> extent of the changes involved. We want to make sure that we are able to
>> respond quickly and efficiently to any issues that may arise from the work
>> being performed.
>>
>> We will update [status.twitter.com] with any changes or additional
>> information about this upgrade.
>>
>
> http://status.twitter.com/post/104738920/planned-maintenance-tomorrow-monday
>
> Thanks,
> Doug
> --
>
> Doug Williams
> Twitter Platform Support
> http://twitter.com/dougw
>
>

[twitter-dev] Re: Planned site maintenance Friday, May 8th 2PM-3PM PST and Monday, May 11th Noon-1PM PST

[Brian Gilham]

Since the message doesn't make it clear (unless my sleep-deprived mind 
is missing it), will this mean downtime?


Jesse Stay wrote:

Can you share what exactly this will affect?  What symptoms will we see?

Thanks,

Jesse

On Thu, May 7, 2009 at 4:21 PM, Doug Williams > wrote:


Prepare your apps! The status blog has the details [1]:

We’re planning a significant database upgrade that will
greatly increase system performance. To do this, we will
require two planned maintenance windows: Friday, May 8th from
2p-3p Pacific and again on Monday, May 11th from Noon-1p Pacific.

We’re taking these maintenance windows earlier in the day
because of the extent of the changes involved. We want to make
sure that we are able to respond quickly and efficiently to
any issues that may arise from the work being performed.

We will update [status.twitter.com
] with any changes or additional
information about this upgrade.

http://status.twitter.com/post/104738920/planned-maintenance-tomorrow-monday

Thanks,
Doug
--

Doug Williams
Twitter Platform Support
http://twitter.com/dougw

[twitter-dev] Twitter4J 2.0.2 released - adding trends api support, gzip support for faster performance

[Yusuke Yamamoto]

Hi all,

I'm glad to announce that Twitter4J 2.0.2 is now available for download.
http://yusuke.homeip.net/twitter4j/en/index.html#download
It'll be available at the Maven central repository in 24 hours.
http://repo1.maven.org/maven2/net/homeip/yusuke/twitter4j/
Until then, you may use the snapshot repository instead.
http://yusuke.homeip.net/maven2/net/homeip/yusuke/twitter4j/

All applications using prior versions are strongly suggested to  
migrate to this release in order to take advantage of the gzip  
compression feature which is twitter.com friendly.


Major features introduced in this release:
- trends API support
Finally Twitter4J supports trends APIs which tells you what is hot in  
twitter.com.

http://yusuke.homeip.net/twitter4j/en/api-support.html#Search%20API%20Methods
- gzip support
As of Twitter4J 2.0.2, it interacts with twitter.com using gzip  
compression method.

No additional configuration, or coding is required.
T4J will start talking to twitter.com in faster and network/ 
twitter.com friendly manner by just using Twitter4J 2.0.2.


Here's the list of fixes included in Twitter4J 2.0.2.
Improvement
[TFJ-131] - Use gzip encoding to improve performance and network  
bandwidth utilization
[TFJ-132] - handle http response codes correctly to reduce unnecessary  
retries

New Feature
[TFJ-120] - include rate limit status in TwitterResponse
[TFJ-123] - support trends methods
[TFJ-124] - support update_profile method
[TFJ-133] - need a way to shutdown async thread gracefully
Cheers,
--
Yusuke Yamamoto
yus...@mac.com

[twitter-dev] Re: Planned site maintenance Friday, May 8th 2PM-3PM PST and Monday, May 11th Noon-1PM PST

[Abraham Williams]

That is usually what "site maintenance" means...

Sent from Dev G1

On May 8, 2009 12:24 AM, "Brian Gilham"  wrote:

 Since the message doesn't make it clear (unless my sleep-deprived mind is
missing it), will this mean downtime?

Jesse Stay wrote: > > Can you share what exactly this will affect?  What
symptoms will we see? > >...

[twitter-dev] Re: Planned site maintenance Friday, May 8th 2PM-3PMPST and Monday, May 11th Noon-1PM PST

[Brian Gilham]

Well, that's true. But, not necessarily. I don't think I was out of line asking 
for clarification. 
-Original Message-
From: Abraham Williams <4bra...@gmail.com>

Date: Fri, 8 May 2009 00:33:09 
To: 
Subject: [twitter-dev] Re: Planned site maintenance Friday, May 8th  2PM-3PM
 PST and Monday, May 11th Noon-1PM PST


That is usually what "site maintenance" means...

Sent from Dev G1

On May 8, 2009 12:24 AM, "Brian Gilham"  wrote:

 Since the message doesn't make it clear (unless my sleep-deprived mind is
missing it), will this mean downtime?

Jesse Stay wrote: > > Can you share what exactly this will affect?  What
symptoms will we see? > >...