October 11, 2010
Web service/infrastructure: HTTP Observer A generalized service for polling a HTTP resource so you don’t have to. The Observer Server has a list of URLs to hit, how frequently to hit them, and who to tell once they’ve changed. Observers register with the server and maintain a persistent TCP connection (to avoid NAT issues; can possibly be changed once IPv6 actually happens). Example ideas: FOAFster (distributed Friendster/MySpace/Facebook using FOAFs); RSS reader; Campfire implementation; a 4chan plugin for Firefox. This can be made easier with libraries for various implementations; a libobserver for C; an observer.js; a Ruby gem probably called something irrelevant like Golden Hawk; pyObserver for Python; and so on.

Web service/infrastructure: HTTP Observer

A generalized service for polling a HTTP resource so you don’t have to.

The Observer Server has a list of URLs to hit, how frequently to hit them, and who to tell once they’ve changed. Observers register with the server and maintain a persistent TCP connection (to avoid NAT issues; can possibly be changed once IPv6 actually happens).

Example ideas: FOAFster (distributed Friendster/MySpace/Facebook using FOAFs); RSS reader; Campfire implementation; a 4chan plugin for Firefox.

This can be made easier with libraries for various implementations; a libobserver for C; an observer.js; a Ruby gem probably called something irrelevant like Golden Hawk; pyObserver for Python; and so on.

1:35am  |   URL: http://tmblr.co/ZRkR6y1CsfvL
Filed under: http observer designpattern webservice webapp infrastructure 
October 11, 2010
Server app/infrastructure layout: how IRC clients (and all network clients) should be done IRC bouncers exist but are the least possible thing that could work, and it shows. Instead it should work like this: The client-controller runs on your VPS, where your screen session or bouncer currently runs. It is interacted with entirely through IRC clients. These clients tell the client-controller which servers to connect to, but also which channel to show in the client, where they last read, which plugins and bots to run, what to search for in the current channel, and everything else that clients do currently. This should all be done on the client-controller instead, and the client becomes a view into that client-controller. IRC is a free-for-all of customizability, so the client-controller needs to handle custom plugins, but it also needs to be replaceable. It must speak a simple and documented protocol and use libraries extensively (libirc, but also … libircclientcontroller?). Something similar exists in Smuxi currently but it is locked into .NET. C’mon. Upon more reflection it makes sense for most client-server networked tools to exist like this. Imagine using w3m to follow along with Epiphany; liferea to follow Google Reader; Evolution to follow mutt; and so on.

Server app/infrastructure layout: how IRC clients (and all network clients) should be done

IRC bouncers exist but are the least possible thing that could work, and it shows. Instead it should work like this:

The client-controller runs on your VPS, where your screen session or bouncer currently runs. It is interacted with entirely through IRC clients. These clients tell the client-controller which servers to connect to, but also which channel to show in the client, where they last read, which plugins and bots to run, what to search for in the current channel, and everything else that clients do currently. This should all be done on the client-controller instead, and the client becomes a view into that client-controller.

IRC is a free-for-all of customizability, so the client-controller needs to handle custom plugins, but it also needs to be replaceable. It must speak a simple and documented protocol and use libraries extensively (libirc, but also … libircclientcontroller?).

Something similar exists in Smuxi currently but it is locked into .NET. C’mon.

Upon more reflection it makes sense for most client-server networked tools to exist like this. Imagine using w3m to follow along with Epiphany; liferea to follow Google Reader; Evolution to follow mutt; and so on.

1:15am  |   URL: http://tmblr.co/ZRkR6y1CsEQ0
Filed under: server, IRC protocol infrastructure networking