[twitter-dev] AD APIs
Hello all, I was wondering does twitter support AD APIs (Similar to Face book AD APIs). Basically the usecase is as follows. I am managing my own campaign for Facebook and similarly I want to do the same for twitter. I want the ability to programatically create and post an AD. Thanks Sri -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Upgrading from Read to Read / Write access for OAuth API Key
Tim - 1. Changing from read to read/write won't change you API consumer keys or tokens. 2. Your application's users don't authorized for read or read/write; they merely use your application, which you offer as read or read/write to the world. That is to say, if it's read, your application can only read its tweets, and if read/write, it can both read its own tweet and post to the world. I'd say go ahead and switch to read/write, given the fact that you now want that functionality. ~Patrick On Sat, Jan 29, 2011 at 10:24 PM, Tim Bull tim.b...@binaryplex.com wrote: We must be about the only developers in the universe that requested users grant only read access when we first got people to connect http://trunk.ly to Twitter (I think of the 40 or so apps authorized on my account, Trunk.ly is the only one that asks for Read only). Never ask for more access than you need is my philosophy. Doh! Of course now, we want to add some Tweet out functions which require users grant us Write access. A couple of questions for the Twitter people. 1. If we change the access in the application from read to read/write does this reset the API key, or will it stay the same (hoping it stays the same). 2. How can I work out if existing users have authorised us for read/ write? I looked at http://developer.twitter.com/doc/get/account/verify_credentials but it doesn't show me what access they have. Do I have to write, fail, force them to step through OAuth then post? Or is there a way of knowing before hand it will fail and asking them to upgrade? Thanks, Tim -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Upgrading from Read to Read / Write access for OAuth API Key
So if a user authorizes an app for read access, the app can switch to read/write at any time without asking the users permission? Is this true? Anyone from Twitter have any input on this? On Sun, Jan 30, 2011 at 11:04 AM, Patrick Kennedy kenned...@gmail.com wrote: Tim - 1. Changing from read to read/write won't change you API consumer keys or tokens. 2. Your application's users don't authorized for read or read/write; they merely use your application, which you offer as read or read/write to the world. That is to say, if it's read, your application can only read its tweets, and if read/write, it can both read its own tweet and post to the world. I'd say go ahead and switch to read/write, given the fact that you now want that functionality. ~Patrick On Sat, Jan 29, 2011 at 10:24 PM, Tim Bull tim.b...@binaryplex.com wrote: We must be about the only developers in the universe that requested users grant only read access when we first got people to connect http://trunk.ly to Twitter (I think of the 40 or so apps authorized on my account, Trunk.ly is the only one that asks for Read only). Never ask for more access than you need is my philosophy. Doh! Of course now, we want to add some Tweet out functions which require users grant us Write access. A couple of questions for the Twitter people. 1. If we change the access in the application from read to read/write does this reset the API key, or will it stay the same (hoping it stays the same). 2. How can I work out if existing users have authorised us for read/ write? I looked at http://developer.twitter.com/doc/get/account/verify_credentials but it doesn't show me what access they have. Do I have to write, fail, force them to step through OAuth then post? Or is there a way of knowing before hand it will fail and asking them to upgrade? Thanks, Tim -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Adam Green Twitter API Consultant and Trainer http://140dev.com @140dev -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Upgrading from Read to Read / Write access for OAuth API Key
You'll have to re-ask your users for permission for write mode and you won't have any way via the API to track who is ready to read/write yet -- you'll want to manage the conversion process yourself and track whether you've converted your users yet or not. The thinking behind this is that when your users authorized your app, they only authorized it for read-access. Wanting write access requires a new agreement with the user. The oauth/authorize step should now upgrade to read/write from read-only tokens when the user is re-challenged. Taylor On Sun, Jan 30, 2011 at 8:32 AM, Adam Green 140...@gmail.com wrote: So if a user authorizes an app for read access, the app can switch to read/write at any time without asking the users permission? Is this true? Anyone from Twitter have any input on this? On Sun, Jan 30, 2011 at 11:04 AM, Patrick Kennedy kenned...@gmail.com wrote: Tim - 1. Changing from read to read/write won't change you API consumer keys or tokens. 2. Your application's users don't authorized for read or read/write; they merely use your application, which you offer as read or read/write to the world. That is to say, if it's read, your application can only read its tweets, and if read/write, it can both read its own tweet and post to the world. I'd say go ahead and switch to read/write, given the fact that you now want that functionality. ~Patrick On Sat, Jan 29, 2011 at 10:24 PM, Tim Bull tim.b...@binaryplex.com wrote: We must be about the only developers in the universe that requested users grant only read access when we first got people to connect http://trunk.ly to Twitter (I think of the 40 or so apps authorized on my account, Trunk.ly is the only one that asks for Read only). Never ask for more access than you need is my philosophy. Doh! Of course now, we want to add some Tweet out functions which require users grant us Write access. A couple of questions for the Twitter people. 1. If we change the access in the application from read to read/write does this reset the API key, or will it stay the same (hoping it stays the same). 2. How can I work out if existing users have authorised us for read/ write? I looked at http://developer.twitter.com/doc/get/account/verify_credentials but it doesn't show me what access they have. Do I have to write, fail, force them to step through OAuth then post? Or is there a way of knowing before hand it will fail and asking them to upgrade? Thanks, Tim -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Adam Green Twitter API Consultant and Trainer http://140dev.com @140dev -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] the Quote tweet and user id
I am not twitter client developer now. But, I have an request for twitter developers. Please treat twitter user id correctly when you implement quote tweet feature. When anyone post the quote tweet via your developed client, if original tweet is very long, your client may cut tweet before post. That behavior have the risk to cut twitter id. For example, the original tweet include @foobar, your client change @foob. @foobar and @foob are different people. Please reply if you have any questions and comments. If you understand Japanese, I can explain this more clearly. thanks. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: Upgrading from Read to Read / Write access for OAuth API Key
OK, that's more or less what I expected. Just one last confirmation - the API key won't change though right? So if I add read / write the read users won't suddenly be de- authenticated? Cheers, Tim On Jan 31, 6:19 am, Taylor Singletary taylorsinglet...@twitter.com wrote: You'll have to re-ask your users for permission for write mode and you won't have any way via the API to track who is ready to read/write yet -- you'll want to manage the conversion process yourself and track whether you've converted your users yet or not. The thinking behind this is that when your users authorized your app, they only authorized it for read-access. Wanting write access requires a new agreement with the user. The oauth/authorize step should now upgrade to read/write from read-only tokens when the user is re-challenged. Taylor On Sun, Jan 30, 2011 at 8:32 AM, Adam Green 140...@gmail.com wrote: So if a user authorizes an app for read access, the app can switch to read/write at any time without asking the users permission? Is this true? Anyone from Twitter have any input on this? On Sun, Jan 30, 2011 at 11:04 AM, Patrick Kennedy kenned...@gmail.com wrote: Tim - 1. Changing from read to read/write won't change you API consumer keys or tokens. 2. Your application's users don't authorized for read or read/write; they merely use your application, which you offer as read or read/write to the world. That is to say, if it's read, your application can only read its tweets, and if read/write, it can both read its own tweet and post to the world. I'd say go ahead and switch to read/write, given the fact that you now want that functionality. ~Patrick On Sat, Jan 29, 2011 at 10:24 PM, Tim Bull tim.b...@binaryplex.com wrote: We must be about the only developers in the universe that requested users grant only read access when we first got people to connect http://trunk.lyto Twitter (I think of the 40 or so apps authorized on my account, Trunk.ly is the only one that asks for Read only). Never ask for more access than you need is my philosophy. Doh! Of course now, we want to add some Tweet out functions which require users grant us Write access. A couple of questions for the Twitter people. 1. If we change the access in the application from read to read/write does this reset the API key, or will it stay the same (hoping it stays the same). 2. How can I work out if existing users have authorised us for read/ write? I looked at http://developer.twitter.com/doc/get/account/verify_credentials but it doesn't show me what access they have. Do I have to write, fail, force them to step through OAuth then post? Or is there a way of knowing before hand it will fail and asking them to upgrade? Thanks, Tim -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Adam Green Twitter API Consultant and Trainer http://140dev.com @140dev -- Twitter developer documentation and resources:http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: European/French POIs results returned are very poor !!
Any news / info ? On 16 jan, 11:52, fvisticot fvisti...@gmail.com wrote: I'm evaluating POIs with Twitter. It seems that results returned by Twitter for french/european countries are very poor. Any idea/improvements planed ? Thank you for your help. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Upgrading from Read to Read / Write access for OAuth API Key
Taylor, Confirmed. I just upgraded read only tokens and was able to successfully send a DM. Thank you for finally allowing read only access tokens to be upgraded to read and write access tokens. This issue has been plaguing developers for almost a year now. Both forcing applications to ask for permission they didn't need if there was even a remote possibility they might want write permissions in the future and biting devs in the ass if they unknowingly built up a customer base of read only tokens. I hope we will continue to see fixes coming down the pipe to keep Twitter API a viable platform for further development. Thank you again, Abraham - Abraham Williams | Hacker Advocate | abrah.am @abraham https://twitter.com/abraham | github.com/abraham | blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private. On Sun, Jan 30, 2011 at 11:19, Taylor Singletary taylorsinglet...@twitter.com wrote: You'll have to re-ask your users for permission for write mode and you won't have any way via the API to track who is ready to read/write yet -- you'll want to manage the conversion process yourself and track whether you've converted your users yet or not. The thinking behind this is that when your users authorized your app, they only authorized it for read-access. Wanting write access requires a new agreement with the user. The oauth/authorize step should now upgrade to read/write from read-only tokens when the user is re-challenged. Taylor On Sun, Jan 30, 2011 at 8:32 AM, Adam Green 140...@gmail.com wrote: So if a user authorizes an app for read access, the app can switch to read/write at any time without asking the users permission? Is this true? Anyone from Twitter have any input on this? On Sun, Jan 30, 2011 at 11:04 AM, Patrick Kennedy kenned...@gmail.com wrote: Tim - 1. Changing from read to read/write won't change you API consumer keys or tokens. 2. Your application's users don't authorized for read or read/write; they merely use your application, which you offer as read or read/write to the world. That is to say, if it's read, your application can only read its tweets, and if read/write, it can both read its own tweet and post to the world. I'd say go ahead and switch to read/write, given the fact that you now want that functionality. ~Patrick On Sat, Jan 29, 2011 at 10:24 PM, Tim Bull tim.b...@binaryplex.com wrote: We must be about the only developers in the universe that requested users grant only read access when we first got people to connect http://trunk.ly to Twitter (I think of the 40 or so apps authorized on my account, Trunk.ly is the only one that asks for Read only). Never ask for more access than you need is my philosophy. Doh! Of course now, we want to add some Tweet out functions which require users grant us Write access. A couple of questions for the Twitter people. 1. If we change the access in the application from read to read/write does this reset the API key, or will it stay the same (hoping it stays the same). 2. How can I work out if existing users have authorised us for read/ write? I looked at http://developer.twitter.com/doc/get/account/verify_credentials but it doesn't show me what access they have. Do I have to write, fail, force them to step through OAuth then post? Or is there a way of knowing before hand it will fail and asking them to upgrade? Thanks, Tim -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Adam Green Twitter API Consultant and Trainer http://140dev.com @140dev -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker:
Re: [twitter-dev] is count parameter applicable for sample stream?
Any idea? -- Yusuke Yamamoto yus...@mac.com this email is: [x] bloggable/tweetable [ ] private follow me on : http://twitter.com/yusukeyamamoto subscribe me at : http://samuraism.jp/ On Jan 22, 2011, at 17:23 , Yusuke Yamamoto wrote: Hi, Is count parameter applicable for sample stream? The doc for statuses/sample says that the method accepts count and delimited parameters. http://dev.twitter.com/pages/streaming_api_methods#statuses-sample But the description for count parameter says that the parameter is applicable for Firehose, Links, Birddog and Shadow clients and the count parameter is not allowed elsewhere. http://dev.twitter.com/pages/streaming_api_methods#count Thanks in advance, -- Yusuke Yamamoto yus...@mac.com this email is: [x] bloggable/tweetable [ ] private follow me on : http://twitter.com/yusukeyamamoto subscribe me at : http://samuraism.jp/ -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] location operator for the Search API
Any idea? -- Yusuke Yamamoto yus...@mac.com this email is: [x] bloggable/tweetable [ ] private follow me on : http://twitter.com/yusukeyamamoto subscribe me at : http://samuraism.jp/ On Jan 24, 2011, at 00:23 , Yusuke Yamamoto wrote: Hi, What is location operator? The doc for the search API addresses location operator in Operator Limits paragraph. http://dev.twitter.com/doc/get/search - location operator: • results are limited to 7 days - But the operator is not listed in the following page: http://search.twitter.com/operators Is the operator really existing? Thanks in advance, -- Yusuke Yamamoto yus...@mac.com this email is: [x] bloggable/tweetable [ ] private follow me on : http://twitter.com/yusukeyamamoto subscribe me at : http://samuraism.jp/ -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: Is there any timestamp for when a user starts following someone?
There's no API method, and no data returned in any of the user calls. If you can regularly retrieve a user's followers you can intuit when (say if you retrieve daily), otherwise there's no way. -- @epc -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] search by location - results lag
Hi all, I have a search by location capture program running and have recently noticed some strange behavior. The program essentially calls the search api roughly every minute, adjusting the since_id parameter to only retrieve new tweets. This was working fine, retrieving a fairly constant number of tweets until sometime around the 19th of December, when I started to notice some strange bursts. Upon investigating this further, it appears that the bursts occur regularly at 15 and 45 minutes past the hour. Looking at the created_at timestamps on the tweets returned each minute, there appears to be an increasing lag between the current time and the most recent tweet returned. The search index then seems to refresh itself at 15 and 45 minutes past the hour and brings itself up to date, only then to slowly fall behind again. I have also been able to replicate this behavior by using the advanced search form and clicking the refresh link every so often. Another thing that I've noticed is that this problem only occurs when the search radius is greater than 35km. I'm not sure what the exact cut off is. Here are some stats I gathered by searching with the following url: http://search.twitter.com/search.json?geocode=-33.867138%2C151.2071%2C100.0kmlang=allrpp=100 (searching around Sydney, NSW with radius 100km) Mon Jan 31 14:02:11 EST 2011 queued 76 messages, timestamp range: 13:55:25 to 13:56:07, lag = 364 secs Mon Jan 31 14:03:12 EST 2011 queued 59 messages, timestamp range: 13:56:09 to 13:56:46, lag = 386 secs Mon Jan 31 14:04:13 EST 2011 queued 71 messages, timestamp range: 13:56:47 to 13:57:21, lag = 412 secs Mon Jan 31 14:05:15 EST 2011 queued 58 messages, timestamp range: 13:57:22 to 13:57:55, lag = 440 secs Mon Jan 31 14:06:15 EST 2011 queued 58 messages, timestamp range: 13:57:55 to 13:58:27, lag = 468 secs Mon Jan 31 14:07:16 EST 2011 queued 53 messages, timestamp range: 13:58:28 to 13:59:01, lag = 495 secs Mon Jan 31 14:08:17 EST 2011 queued 75 messages, timestamp range: 13:59:03 to 13:59:35, lag = 522 secs Mon Jan 31 14:09:18 EST 2011 queued 80 messages, timestamp range: 13:59:35 to 14:00:07, lag = 551 secs Mon Jan 31 14:10:19 EST 2011 queued 85 messages, timestamp range: 14:00:08 to 14:00:38, lag = 581 secs Mon Jan 31 14:11:19 EST 2011 queued 64 messages, timestamp range: 14:00:38 to 14:01:14, lag = 605 secs Mon Jan 31 14:12:20 EST 2011 queued 82 messages, timestamp range: 14:01:16 to 14:01:51, lag = 629 secs Mon Jan 31 14:13:21 EST 2011 queued 68 messages, timestamp range: 14:01:51 to 14:02:28, lag = 653 secs Mon Jan 31 14:14:22 EST 2011 queued 73 messages, timestamp range: 14:02:29 to 14:03:05, lag = 677 secs Mon Jan 31 14:15:38 EST 2011 queued 1500 messages, timestamp range: 14:03:39 to 14:15:38, lag = 0 secs Mon Jan 31 14:16:39 EST 2011 queued 74 messages, timestamp range: 14:15:38 to 14:16:10, lag = 29 secs Mon Jan 31 14:17:40 EST 2011 queued 79 messages, timestamp range: 14:16:11 to 14:16:54, lag = 46 secs Mon Jan 31 14:18:41 EST 2011 queued 81 messages, timestamp range: 14:16:56 to 14:17:36, lag = 65 secs Mon Jan 31 14:19:41 EST 2011 queued 82 messages, timestamp range: 14:17:36 to 14:18:18, lag = 83 secs Mon Jan 31 14:20:42 EST 2011 queued 71 messages, timestamp range: 14:18:18 to 14:18:58, lag = 104 secs Mon Jan 31 14:21:43 EST 2011 queued 73 messages, timestamp range: 14:18:59 to 14:19:38, lag = 125 secs Mon Jan 31 14:22:44 EST 2011 queued 63 messages, timestamp range: 14:19:38 to 14:20:15, lag = 149 secs Mon Jan 31 14:23:44 EST 2011 queued 55 messages, timestamp range: 14:20:16 to 14:20:54, lag = 170 secs Mon Jan 31 14:24:45 EST 2011 queued 64 messages, timestamp range: 14:20:55 to 14:21:34, lag = 191 secs Mon Jan 31 14:25:46 EST 2011 queued 77 messages, timestamp range: 14:21:36 to 14:22:15, lag = 211 secs Mon Jan 31 14:26:47 EST 2011 queued 85 messages, timestamp range: 14:22:16 to 14:22:58, lag = 229 secs Mon Jan 31 14:27:48 EST 2011 queued 89 messages, timestamp range: 14:22:59 to 14:23:40, lag = 248 secs Mon Jan 31 14:28:50 EST 2011 queued 75 messages, timestamp range: 14:23:42 to 14:24:21, lag = 269 secs Mon Jan 31 14:29:50 EST 2011 queued 83 messages, timestamp range: 14:24:22 to 14:25:03, lag = 287 secs Mon Jan 31 14:30:51 EST 2011 queued 77 messages, timestamp range: 14:25:03 to 14:25:42, lag = 309 secs Mon Jan 31 14:31:52 EST 2011 queued 59 messages, timestamp range: 14:25:44 to 14:26:19, lag = 333 secs Mon Jan 31 14:32:53 EST 2011 queued 62 messages, timestamp range: 14:26:19 to 14:26:57, lag = 356 secs Mon Jan 31 14:33:53 EST 2011 queued 74 messages, timestamp range: 14:26:58 to 14:27:35, lag = 378 secs Mon Jan 31 14:34:54 EST 2011 queued 42 messages, timestamp range: 14:27:37 to 14:28:08, lag = 406 secs Mon Jan 31 14:35:55 EST 2011 queued 62 messages, timestamp range: 14:28:10 to 14:28:44, lag = 431 secs Mon Jan 31 14:36:56 EST 2011 queued 72 messages, timestamp range: 14:28:46 to 14:29:18, lag = 458 secs Mon Jan 31 14:37:57 EST 2011 queued 64 messages, timestamp range:
