All messes have to begin somewhere. It is unfortunate that they often begin as a simple and elegant idea. It's only somewhere near the middle that we recognize the simplicity and elegance of our initial thoughts for what they are: half-baked schemes which will eventually fall apart.

When I struck out to learn IronPython, I certainly never intended for that process to become a mess. But ... it did. A simple first project became unnecessarily complicated and then later necessarily complicated. That level of complexity (for argument's sake, let's call it sophistication) resulted in a first level of dependencies. Those dependencies then led to a few more and in such a fashion, the scope of my original project mushroomed. So, I have found myself learning about multithreaded applications when all I really wanted to do was write Hello World. There is a bright side here, the big complicated mess has led to something that, while sophisticated, will also became useful (eventually). Allow me to explain.

Plans and Architecture

Some Background

In Part 1 of this series, I described my desire to learn a new programming language and briefly described my setup. While that article meant to describe my rationale for learning Python (really meant to answer the question, "Why bother?"), it didn't describe how I intended to do so. That is how I will begin this article. My plan has its roots in the "learning process." So, let me begin by talking about students.

I have worked with a number of students. This includes high school students, undergraduate college students, graduate students, and medical students. Despite the difference in type of study and age, all students have several things in common. The first of these is a tremendous terror of doing something wrong. It is, therefore, somewhat puzzling that this same terror seems to preclude many students from learning anything of worth. I have found that the easiest way to break the fear is through forced action. This is the basis for the manner in which medical students are trained, namely: monkey see, monkey do, monkey teach.

So, when I set out to learn IronPython, I decided that I needed to have a project to motivate me. But it couldn't be just any project, oh no. It had to a real and useful project. Nonuseful projects and tutorials certainly have their place, but it should not be in education. As you might guess, there is a story behind this. While an undergraduate engineering student in college, I suffered through a rite of passage inflicted on all new students: Computer Science 1100 – Introduction to Java. My highly refined (and somewhat irrational) distaste and dislike of Java stems from this one course. It was awful! We followed the standard programming text and advanced from one useless example to the next without ever being shown how the concepts and techniques were integrated. It wasn't until I was forced to start doing real things in Matlab that I finally gained an appreciation of programming, and even found that it could be fun.

Basic Project Development

So, to learn IronPython, I need a project which I feel is real. It needs to be something that I can (and will) use after it is completed. Useful software that lasts a long time starts by addressing a very specific need, and doing that well. After reflecting on my needs, I have found two "itches" which needed to be scratched. While I haven't written a lot of software, I have helped design quite a bit of software and there is a process to it.

• First, you clearly define what need the project is supposed to address and its scope.
• Following that, you begin talking about what components are needed to address the need.
• After carefully defining the components, you lay a gridwork for the "back" end of the application.
• You then iterate and discuss. While the first three steps will lay out the various pieces, discussion helps to refine the gridwork and plumbing.
• Draft a plan and start writing code. Continue to iterate and discuss as challenges arise.

My Projects

After reflecting on my needs, there are two relatively simple programs I've wanted/needed for quite some time. The first is a Windows podcast aggregator and the second is a simple BibTeX manager. In this post, I will describe the first in some detail. The BibTeX manager, which is much more complex, will be a subject of a later post.

PodCatcher – A Simple Podcast Aggregator

I really, really dislike iTunes. It has therefore been a point of frustration for a long time that Windows lacks a really useful Podcasting client that is nicely integrated with Internet Explorer and Windows Media Player.

A few years ago, I did a little bit of digging to see if I could jury rig one. What I found frustrated me even more. All of the base technologies for a great podcast aggregator are there. In Internet Explorer, there is a very nice RSS platform which other applications can leverage. Further, Windows Media Player 11 is a very nicely done media player. While I have used iTunes, WinAmp and others, I eventually end up returning to Windows Media Player as a default. It's there, it works, and it manages a very large library very well.

With the combination of the built-in RSS client and Windows Media Player/Center, it defies logic that there isn't a Podcast aggregator! All that is really needed is a simple GUI to link the two services. Windows Media Player can be used for media playback and Internet Explorer can be used for subscriptions. This combination also best reflects my workflow. I tend to discover most podcasts while browsing the internet, it is therefore more natural to click a button in Internet Explorer instead of pasting the Url into a second program.

Real Life Complexity

While the original idea was indeed elegant and simple, real life intruded quickly. Following the tutorials available in IronPython in Action, I was able to quickly get up and running. I obtained a copy of the Microsoft.Interop.Feeds dll file needed to interface with the feeds engine. By using a for loop, I was able to view the RSS folders and feeds available in my system store. Very cool! What I didn't anticipate, however, was that while the RSS subscription functions are very well thought out, the enclosure download service is not. When testing a very popular podcast, Science Friday from NPR, the download engine failed on 75% of the enclosures. There were a variety of errors, but one of the most common was an error saying that the download enclosure was too big. After reading the RSS platform documentation, I discovered that this design was intentional; which prompted a colorful rant that wouldn't be prudent to include here.

While trying to sort out the download errors, I also discovered a second major issue. The download engine stores its files in the Internet Explorer Temporary Files folder. I discovered that emptying the temporary files also deleted my downloaded podcasts. This prompted a second, colorful rant. I got in touch with the Windows RSS team and inquired about programmatically changing the location of downloaded enclosures. The existing feeds engine does not support this feature.

So, in addition to my simple GUI, I found that I apparently needed a write download manager as well. Luckily, the Windows RSS platform provided an excellent blueprint to get me started in the existing download manager. Aside from the location of the files and an arbitrary download limit that was set arbitrarily too low, the download engine had a surprisingly robust architecture. Actual downloads are handled by the Background Intelligent Transfer Service (BITS). This gives it a number of very attractive features:

• Asynchronous downloads that happen in the foreground or background
• The ability to preserve the network responsiveness of other applications
• The ability to resume file transfers after network disconnects or computer restarts
• It is built into all copies of Windows, which means no additional downloads or dependencies!

I, understandably, became quite excited about this little gem. I then discovered a second problem, there isn't a managed code interface. Cue third colorful rant. In deep despair, I did not abandon hope completely. Instead, I went to consult the great oracle of Google and … I was in luck. Some noble individual had already written a C# wrapper for BITS, and it even had an introductory article posted on CodeProject. Back in business!

Here, then, were the specs of my little download manager:

1. Based on BITS with the ability to pause, resume and continue downloads in the background.
2. Managed code interface with BITS
3. Written in IronPython.
4. A GUI which updates the user on the current download status.

What about looks?

With some idea of what I wanted on the back end, I then started to think about the front end interface. This necessitates a confession: I am an incredibly vain person. I expect for my software to be pretty. While I will be using Windows Vista to develop the program, I have come to thoroughly appreciate the aesthetics of the Mac OS. As a result, any GUI that I create needs to be simple, elegant and highly functional. While I still hadn't create a mock for the GUI for PodCatcher, I already had a fairly good idea of what I wanted the download manager GUI to look like.

While this may (should) look familiar, it captures what I am looking for in my download manager perfectly. I want the interface to be straightforward and elegant, yet convey a tremendous amount of information. For each podcast, this will include the Podcast photo (at far left), the title of the podcast episode being downloaded (along the top), the title of the podcast feed (bottom), and the size. Completed downloads would include the date/time which they finished downloading. Downloads in progress would include a progress bar with the option to cancel or pause. Paused downloads will have a button for them to resume. Given my vain and superficial nature, I wanted my download manager to be beautiful. After some superficial research, I decided that I would use Windows Presentation Foundation (WPF) as the basis of my GUI.

Revel In Complexity

Iterating through my design process made my "simple" project a great deal more complex. Indeed, it made a brilliant mess. Instead of tackling a new computer language, I have signed myself up for a great deal more. First, there is Python and IronPython. Next, there is the .Net framework. Finally, there is WPF (a computer language in its own right). I also discovered something regarding WPF and IronPython. While Windows Forms and IronPython have fantastic documentation and a number of very useful tutorials, there isn't as much written about WPF and IronPython. I will therefore need to do quite a bit of ciphering on my own. The vertical stage of my Python learning curve just got a bit higher, though a useful and real world example is starting to emerge. In the next article in this series, I will explain how I have started to tackle the first component of my podcast aggregator: a beautiful, multithreaded download manager.

Similar Posts:

• IronPython – Windows Presentation Foundation Tutorials
• Learning IronPython – Part 3 – A Beautiful Start
• Learning IronPython – Part 4 – BITS and Pieces
• Learning IronPython - Part 6 - From Rudimentary to Functional
• IronPython - Data Binding and Data Templates - Part 1

Categories: IronPython, Programming
5 Comments »