jwz
 | 04:03 am - mixtape 040
 Please enjoy jwz mixtape 040.
Tonight was the final Pop Roxx event. To commemorate this, we gave away a bunch of compilation CDs of most of the bands who have played at Pop Roxx over the last two and a half  years. It wasn't all of the bands, because there were too many to fit on an audio CD, so I had to leave a few off. This week's mixtape is the "director's cut" of that CD: it's almost the complete set of Pop Roxx bands. (And yeah, I'm slightly breaking my "C90" rule for this one.) I'm only missing tracks by three bands (Pretty Vicious, Landshark, and Sunday Drivers). Somehow I managed not to get CDs by those bands, and I wasn't able to track down MP3s by them this week, alas. We had a lot of great bands at Pop Roxx! I'll miss it.
Current Music: as noted
|
jwz
| 03:58 pm - Tentacles?
They seem to have thrown away something amazing here... 
|
perl
[paintitmatt]
 | 02:55 pm - Perl and Pidgin's API
I'm trying to write a plugin for the Pidgin IM client in Perl that would take your latest post to http://identi.ca from an RSS feed and set it as your Pidgin status message. However the Perl API for Pidgin is poorly documented and I'm having trouble. I based a lot of it on the pidgintwitter-plugin.
I'm not sure what's going on exactly though I suspect I'm not passing the URL correctly to the the parsing subroutine.
Any help would be appreciated.
( code behind the cut )
|
evan_tech
[evan]
 | 10:22 am - heavy protocols add up
I found this discussion of Android's dropping XMPP interesting. (Disclosure: I have no insider knowledge about any of this.) In particular, this remark about compression in the context of the notoriously fat XMPP protocol:Bandwidth used means radio transmissions sent, and overhead means more work done by the processor, both of which take battery power and reduce battery life. Meanwhile, compression turned out to not be very helpful. Since it's negotiated during connection startup, it doesn't help with startup overhead. It does help somewhat with steady-state bandwidth, but at the expense of additional CPU cycles. The result is that enabling compression actually reduced battery life in our tests -- it took more power for the CPU to do compression than we saved on radio power. (I wonder though: perhaps they could've used a simpler form of compression? XML ought to be "easy" to compress. Maybe the spec doesn't allow it?)
You see a similar phenomenon with HTTP on a heavy page. Like CNN.com: Firebug says it took 135 HTTP requests to load the page. Many of them are to a CDN and only have ~400 bytes of request headers but all the ones to cnn.com (including the ads, apparently!) include cookies pushing them up to nearly a kilobyte. The net result is that the latency of the page starts getting affected by the end-user's upstream bandwidth, which is usually terrible. (But now, having typed that out, I wonder: does it really matter? Even those heavier requests fit within a packet anyway...)
|
![[info]](http://p-stat.livejournal.com/img/userinfo.gif){kind=small}
krunal's Friends Page