I've Been Thinking About This…

I got all excited about 3 months ago and decided to write a verse-of-the-day Twitter-bot. I had just bumped into Twitter a few days earlier (we don’t have a lot of this techy-stuff out here in New England), and I thought ‘just the thing’. Then the trouble started.

To create a Twitter-bot you need to be a web server. By definition, web servers are passive – ‘send me something and I’ll reply to you’ sort of thing. By definition many Twitter-bots are also passive – ‘I’m waiting for your command to obey it’, but some Twitter-bots are active. There are 2 types of ‘bot invocations:

• A ‘push’ sends a broadcast message. That means that the push functionality has to wake up at a time (say midnight) and push the message out to all subscribers (friends) … again, waking up to send a message is not a typical web function, but at least it’s only once a day.
• A ‘pull’ waits for a request and fulfills it. That’s great, just like a web site.

Unfortunately, it appears that initiating a connection between the user and my verse of the day ‘bot requires the user to add the ‘bot as a friend, and then the ‘bot has to add the user as a friend. How does the ‘bot know that the user wants it to add him as a friend? IT HAS TO LISTEN TO A ‘befriend_all’ LINK EVERY 30 SECONDS!!!!!

Gack! This is the old ‘poll’ technique that was kicked into the trashcan back in the ‘80’s (think RJE stations). It means transmitting an active message twice a minute from the passive web site. Not a smart design. (BTW, it doesn’t have to be 30 seconds, but – as I understand it – that interval gives reasonably responsive feedback to the user so he/she can see that they’ve been added and prevents frustration and multiple messages.) It also means that every Twitter-bot everywhere is sending Twitter an automated message every 30 seconds (or what ever their interval is) – just for a response that is almost always ‘no change’. No wonder Twitter is crashing so much from overload – every ‘bot in the Twitter-sphere is polling it every 30 seconds to check for a message that might show up a dozen times a day!

(I’ll insert my disclaimer here: the documentation for Twitter-bots is {or was!} very sketchy – basically just an API at the time I was investigating doing this – so I may have mis-read how the thing works.)

I wanted to do both: pull – serve a verse from the DB when the request came through from anyone, and push – serve the verse of the day from the DB at midnight to everybody subscribed.

Now Twitter handles different end-point devices differently:

• When someone is subscribed as a mobile phone user and is added as a friend, Twitter sends the ‘add’ message out to them.
• When someone is subscribed as an email user and is added as a friend, Twitter sends the ‘add’ message out to them.
• But when a Twitter-bot is added as a friend, Twitter makes it come look for the ‘add’ message. Why? Isn’t this a staggering waste of traffic?

So I propose a new type of ‘bot – the 2bot, if you will – where Twitter owns the timer and control feed. Here’s how it would work:

1. When I register my 2bot, I tell Twitter it’s a 2bot, and possibly the wake-up time (midnight) and/or the frequency (86400 seconds, in my case).
2. Every time someone wants to subscribe to my service, Twitter sends the 2bot their name and, like a good little web site, I’m woken up and register them, sending them a friend request in reply. When they accept back to me, I send an acknowledgement and go back to sleep. No more polling 2880 times a day for a dozen messages!
3. When they want info (pull), I reply as before.
4. When it’s time to push, I get Twitter’s chron message and send the broadcast out – actually, with this architecture the push just became a pull, didn’t it?

Result? A simpler web site on my side without chron cards – I go back to being a basic web site doing only what I was supposed to do – and a much, much lower load of traffic on Twitter’s side; both benefits leading to less down-time.

I think they should pay me a few mill for this.

   Send article as PDF