Podcasting in Windows Media Player: BitTorrent?

Window Media Player logo BitTorrrent logo

In yesterday’s “Daily Source Code", Adam Curry is talking about his meeting in Redmond with the Windows Media Player team.

Adam says he can’t tell anything… but what else could this probably mean than Windows Media Player supporting podcasting – or “blogcasting” as they like to call it in Redmond ?

What could Microsoft possibly add to get their Media Player ahead of iTunes? Video? No way: iTunes has had that for even longer than the iPod video.

If I was Microsoft (yeah, right :>>) I’d definitely add all podcasting features you can find in iTunes and I’d add this little extra: BitTorrent distribution! (Or any other P2P distribution method if I had a political/licensing problem with BitTorrent…)

Today, independant podcasters can easily put their shows online, but as soon as they get popular, they face a huge problem: bandwidth!

The current podcasting architecture relies on a central server for each podcast and independant podcasters just can’t afford the bandwidth it’s going to take. And it only gets worse with video-casting.

Right now they have no alternative other than paying the bills and financing them by adding advertisements to their shows. A peer-2-peer add-on to the architecture would change the deal significantly. We all know how large files get distributed easily that way.

Of course the risk is for the system to be hijacked in order to illegally distribute copyrighted material… This is why Apple hasn’t done it in the first place. Will Microsoft have the guts to do it? Hum…

Does Microsoft only need to do something like this? Well… yes… sort of. They’ve lost the leadership in digital contents already and they’re losing a lot of momentum too. Besides, they have finally realized they needed a damn good IE7 after swearing there would never be a new browser after IE6… Now they realize they need a damn good new Media Player…

Can’t wait to see what’s in it!

Why I consider (MVC) Smarty templating inefficient

Most PHP developers (and other web developpers too) seem to evolve on a similar path which goes like this:

Step 1: take HTML pages an add PHP tags into them.

Step 2: Realize that on a large scale this is getting very hard to maintain.

Step 3: Learn about the MVC (Model View Controller) paradigm and begin to think it's cool.

Step 4: Use Smarty or another templating engine like that.

The way most of those templating engines work is basically this:
a) Do a ton of PHP processing in the framework and fill in variables.
b) Call smarty and let it fill in variables in a template.
c) Send the output.

The issue here is that during steps a and b, nothing is sent back to the user. The user is just waiting for a response. Sadly enough, steps a and b will take a lot of precessing time. So the user will wait quite a long time before he gets any feedback on his action.

Even worse, when the application gets bigger, step a will take even more time!
And the more complex page you request, the more time you'll be left in the dark...

This is why I don't like all those mainstream templating engines. I want to send output back to the user as soon as possible. I want to send the page header at the begining of step a. And as soon as something has been processed and is ready for display, I want to send it out.

The global processing time will be approximately the same, but if the user sees content begining to display immediately, instead of all the content displaying at once 2 seconds after clicking, he will get the (false but humanely useful) impression that the application is faster. (Please do not say AJAX here, it is so not my point :P)

I'm not saying MVC is a bad paradigm, I'm saying most implementations of MVC are flawed, and Smarty is the most common example of this in PHP. Because they do the M & C stuff and then they do the V (view) stuff at the end. In my opinion they definitely need to interleave all this a lot more.

In evoCore (b2evolution's framework) our approach is to have the Controller really control the processing flow. In other words: for every block of information the View wants to display, the Control will process data from the Model and immediately pass it to the View in order to display the result block by block.

Of course, this has drawbacks: you won't be able to change the block order of the output if it's hard coded into the Controller. But really, that's okay to some extent. Who really needs to move the global header and the global footer for example? This is what we use for the back-office.

However, for the front-office, we want more customization, and we want people to be able to rearrange blocks in any order. In this case we have a little more complex processing, where the View actually calls the controller everytime it needs to display something.

Anyway, in any situation, my point is: the View should not be handled last.

Efficient vs. effective

Guy 1: I am so efficient I can fold 100 parachutes in a hour.

Guy 2: I am so effective I can fold 100 parachutes and every single one of them will open right.

Would you rather give your parachutes to the efficient or to the effective guy?

Now what I'd like to know is why all these programmers we interview pride themselves on being efficient?

I'm so sick of their industrial strength bug generating skills... :/

Deep into Sleep

While researchers probe sleep's functions, sleep itself is becoming a lost art.

Stickgold compares sleep deprivation to eating disorders. “Twenty years ago, bulimics probably thought they had the best of all worlds,” he says. “They could eat all they wanted and never gain weight. Now we know that they were and are doing major damage to their bodies and suffering major psychological damage. We live in a world of sleep bulimia, where we binge on weekends and purge during the week.”

iPod podcast listening frustration

Today, I've got this massive stack of clothes to iron... bleh :(

To make the experience a tiny little bit more pleasant, I'm listening to every podcast on my iPod I hadn't listened to yet...

Great time to catch up with all that stuff... but great frustration too!

A typical podcast has an average length of 15 minutes. And when the iPod is done with playing it, it just goes back to the main menu. Yes, that's the MAIN menu, not the podcast feed you where in, not the podcast menu either! It's all the way back to the main menu!

So you need to drill down into the podcast menu again and then into the feed you were listening too, select the next podcast you want to listen to and then, finally, you can continue to listen...

Wouldn't it have made sense for the iPod to automagically playthe next episode in the feed I was listening too!? Isn't the whole podcast concept somewhat supposed to mimic a radio with better programs? Do you need to click on your radio in order to listen to the next show?

Apple seems to have thought this through... at some point... but only halfway I guess: you can actually press play when a podcast feed is selected and the whole feed will get played. But in this case you'll suffer 2 major problems:

  • You'll listen to the feed in reverse chronological order. And you'll hear feedback on the previous episode before you hear the referred to episode! :(
  • You'll listen to everything, including the episodes you've already listened to before...

This second point is something else that has been bugging me for a while: there's no way you can see on your iPod what episodes you've already listened to and which ones are new.

Each episode definitely needs a 3 state icon in front of its title, indicating wether it's unplayed, partially played or completely played.