-Here's one way in which I disagree with the authors of LIRC: they've managed
-to cram support for practically every protocol used by every remote control
-ever made into a single codepath. So, there's a single "transmit" function,
-sorting through a massive pile of flags, conditional statements, and some
-really funky delayed-action buffering to make everything work. The simple act
-of splitting the code into one routine for the RC5 (biphase) protocol and
-another for the NEC (space-encoded) protocol makes it much easier to read, at
-least to my eyes. (I haven't yet implemented the RC6 or other protocols.)
+As I have progressed in adding support for additional IR protocols, I'm
+beginning to see why the authors of the LIRC made the attempt to compress
+every possible IR protocol into a straightforward count of individual IR
+pulses. The total number of IR protocols in use is amazing, and many of them
+(through oversight or due to the longevity of their use) are mind-numbingly
+complicated to deal with. Still, I believe that separating the major protocols
+into their own code paths results in code that is easier to understand and
+maintain; I'm slowly moving away from the LIRC's system to my own as time
+goes on.