![[Back to the Floodgap main page]](/pix/hosted.gif "[Back to the Floodgap main page]")
Return to the TTYtter main page
*** The public beta of TTYtter is currently at version 2.0.0 beta 4 (27 January 2012). Please read this ENTIRE page.
If you suffer from a distinct lack of adventure, supermodels or large wads of cash in your life, then this page will almost certainly be of little help. However, if you want to be on the bleeding edge of what the (IMNSHO) best text-based Twitter client available is offering, then you have come to the right place.
Periodically as development commences on new versions of TTYtter, public betas will be made available for finding bugs, testing compatibility with extensions, and general merriment. These betas are for testing prior for release, not for feature suggestions. Feature suggestions will be deferred to future versions; please don't make them during the public beta period. If you find a bug or a serious deficiency in the public beta release, you are expected to tell @ttytter or send mail to ckaiser@floodgap.com, which is the price of being as cool as you are about to be.
Once the public beta has achieved "adequate" (as defined by the maintainer) exposure and pounding-on, it will be converted into the release version. The next beta will become available after internal alpha testing, though usually not immediately.
When we get to saving state in 2.1, then you'll just be able to /add filter ||/\b\@famoususerwithgroupies\b/i and /save, but that's not in this version. Just salivate quietly on your keyboard. However, to make this easier for now, your filter setting is now reported to you at the end.
Anyway, to turn on the flood, use -streamallreplies (this is not the same thing as -mentions: you'll see).
Streaming support is not enabled by default. You must be using OAuth
(and therefore cURL) and SSL, and you have to ask for streaming to
be enabled with the -dostream option (or put dostream=1
in your .ttytterrc). If TTYtter still doesn't like you
think you have met the prerequisites, you will get an informational message
when you start the client and standard REST API will be used.
Streaming API support is layered on top of the base client, and the REST API is still used (explanation momentarily). When you start in streaming mode, the standard foreground and background processes start up, but also a buffer process and a nurse process which manage the streaming socket opened by cURL (the nurse passes credentials to cURL and monitors its health; the buffer ensures that synchronization is maintained and transparently proxies data to the background). Instead of updates only happening as scheduled with -pause, TTYtter will display tweets, DMs and events as they are pushed over the socket in near-real-time. If the connection is lost, it will be automatically and silently reconnected; if TTYtter is unable to reconnect, while it keeps trying it will transparently fall back on the REST API. When you stop TTYtter, there is a brief pause while it cleans up the additional processes. For compatibility with the widest range of systems, processes are used instead of threads.
REST API is still used to back up your stream. Besides acting as a fail-safe, tracked terms (-track) still pull from the Search API as TTYtter supports larger numbers of and more complex search terms than the Streaming API does. If you enable lists, those are also fetched from the REST API, and if you say /set notimeline, streamed events are simply thrown away as you would expect.
The streaming API is somewhat different than the REST API. Retweets are pushed directly to you so you can see when you have been retweeted by someone, whether or not you follow them, and replies to you are always sent even if you don't follow them either (so you don't need -mentions). If you don't want that, you can use the option -nostreamreplies, and then your timeline alone will be used to fetch replies (albeit more slowly). Incidentally, using -mentions and -nostreamreplies together is stupid. The streaming API also echoes copies of DMs you send, so you can use them to have a conversation, as well as your regular tweets. Retweet counts may differ or even be zero when streamed to you, because they will not have been retweeted as many times or at all compared to when they would have appeared in your timeline normally.
Streaming API support also includes events. The currently supported events include (un)favouriting, following (but not unfollowing) and deletions, relative to you (so you can see when someone (un)favourites a tweet, or starts following you). Events don't receive a menu code and are simply displayed. Because deletions have an impoverished JSON representation relative to the other objects, you are simply advised that a deletion event has occurred, since odds are you've already seen the deleted tweet.
-daemon mode works with streams too. No modification should be needed to your code and the regular TTYtter API methods still hold (there is a new $eventhandle for you to hook to get events). However, if you use streams with a bot, you should read Twitter's Streaming API documentation to ensure that your usage meets terms of service. TTYtter only supports User Streams; it does not support Site Streams.
If you have a large number of simultaneous sessions running attaching to different user accounts from the same host, Twitter may disconnect or refuse you access. Unfortunately, this is likely to happen with shared hosts like SDF. Sorry; let's see if they'll grant the Fortress an exception.
Because realtime updates will definitely disturb people using the basic client, you are strongly advised to use Term::ReadLine::TTYtter or some other readline agent with streaming.
Cameron Kaiser