I mentioned this to my buddies at Santa Barbara Hacker Space and we made it a collaborative project. I’ll miss this week’s WebTech Wednesday session, but perhaps a write up will help keep the conversation going.
The idea is pretty simple. There are three components.
- The tweet engine
- The datastore
- CRUD Interfaces to the data store
The tweet engine will query the datastore every so often and see if there are any tweets that need to be tweeted (because their tweet_by timestamp is in the past).
The datastore will hold the tweets and their tweet_by time, stored as UTC timestamps.
The CRUD interface will let us create, read, update and delete those tweets.
- Use Twitter authentication for accessing the app
- Bulk uploader for multiple tweets.
- Support multiple users
- Support queues of tweets, which get tweeted at a regular schedule
- Support additional entity data with the tweets, such as geolocation
- Managing the timestamp will take some thought. The CRUD interface should use localtime—with an option to override the timezone—but store UTC in the database. That will avoid some common problems with tweets going out on the server’s time zone when the user thought it was set for theirs.
- This first version will, unfortunately, be totally exposed to anyone who knows the URL. We’ll add twitter authentication as soon as possible.
- Timing the engine will take some finesse. We could just poll the database, but that wastes a lot of cycles. Instead, I’d like the engine to schedule itself to run at the next tweet_by time and have the CRUD either wake the process up early or kill & restart it.
That’s it for the start. More as it happens.