This is Denby.

I mention in the video that it’ll end up being “like TweetDeck”. I breezed past that a tad too quickly — it’s definitely not going to be an HTML5 clone of TweetDeck! (Turns out they’re working on one of those already.)

Instead, it will take inspiration from the multi-column approach, but hopefully improve the user experience on a number of levels:

• It’ll be 100% Free Software / Open Source… and one hopes, peer produced.
• JavaScript on the server, JavaScript on the client, with liberal doses of “HTML5″ (the platform your platform could be), whatever that means to you.
• No Adobe AIR, and thus, no vicious memory and CPU abuse! Seriously: Firefox TweetDeck is wasting more CPU time sitting “idle” than Chromium and node.js are using to run Denby. Oh, and node.js is 12MB resident.
• It can work a bit like a desktop app… use the “web page as application” tool your browser provides. Firefox has Prism, Chromium has… a menu item. Denby will support things like desktop notifications, audio bleeps, drag-n-drop (for media uploads), inline display of media, etc.
• Run local or hosted. Once I’m happy with the user experience, I’ll start thinking about cool things the server could do while you’re not connected to it! For now, it only maintains the connection to Twitter while a client is connected.
• I want to build delicious multiple account support, without complicating the single account experience. It’ll merge streams, detect the context you’re acting upon (click reply and you’ll be replying from the appropriate account), etc.

Please comment if you have any thoughts or suggestions… crimes committed by other Twitter clients, ideas for lovely web/desktop integration, and so on. Thanks!

HELLO DENBY.

* * *

Note that I’ve already had questions about StatusNet and identi.ca support. Thus far, they don’t have user streams, which was one of the main reasons behind building Denby. That said, it is entirely possible for the Denby server to poll the REST API (given that it already talks to Twitter’s) and send the results down the WebSockets tube… so, we’ll see.

Hmm. Perhaps this is the best way to build a user streams API for StatusNet anyway? The web app could send JSON messages to node.js, which could relay them to the intended users… via multiple protocols! Long-running HTTP, WebSockets, whatever. If anyone is inspired to do this, StatusNet could have a bi-directional WebSockets API before Twitter does!

* * *

Update: I made another quick video, showing a few improvements (including update bleeps — no chicken noises as yet), Denby in Firefox’s Prism environment, and sharing some thoughts about the web as a development platform. Enjoy!

… and apparently available on Zazzle.

The problem with Apache processes is that they’re big: they chug a lot of memory, and take a long time to get started. Sure, Apache includes a number of slightly more modern process models than the traditional prefork MPM, unfortunately (and predictably enough), PHP keeps us mired in the land of suckage. So when it comes to memory abuse, I was delighted with the results of putting nginx in front of Apache, and giving it complete responsibility for static files:

Reduced memory usage, increased capacity for OS level disk caching, and of course, consistency. Consistency wins every time. Any sysadmin who has had to react to a sudden change in usage patterns will grok the importance of consistency — after all, it’s not being slashdotted or dugg that will kill you, it’s the hardware and software configuration designed for your everyday load.

That’s all very good for Mr. Server Administrator, but nothing is truly measured until we understand the impact on users. Friday lunch time? Business as usual…

… maaaaybe just a little quicker if they were paying attention. Not that you can tell from this chart.

So, I’m pretty happy with nginx sitting in front of Apache. It totally changes the performance characteristics of the server (and website!) for the better, while allowing me to fall back on somewhat more mature and extensive Apache features when I need to. For instance, nginx’s rewrite module is pretty good, but Apache’s mod_rewrite is truly the original and the best (read: most insane). Surprisingly, nginx doesn’t support old school CGI, but I suppose most of the cool kids using it are opting for better process models such as FastCGI and proxied application servers anyway.

The biggest win in this instance was the conversion of a caching mod_proxy frontend — lot of static files, inefficiently served by Apache — to the new, inbuilt caching module in nginx 0.7. Initially I had tried the apparently popular ncache — must be a lot of people talking about it hypothetically, methinks — but it is probably best described as an “out-of-tree design, configuration and implementation fail”. Once I sucked up the fear-of-trunk and tried the caching support in nginx 0.7, there was no looking back.

(Finally, a quick shout-out for collectd 4.6.2 and the relatively new collection3 web frontend for it… sadly, I switched to it after these charts were saved, so you don’t get to see the new hotness. Maybe you should try it on your server?)