It’s not quite out the door yet, but things have gotten quieter around here since we shipped the Release Candidate of 2.6. But there’s no rest for the dynamic, so we’ve already started thinking about what we do next.

Since we shipped 2.0 last December, we’ve shipped two service releases: 2.0.1 two months later in February and 2.0.2 four months after that in June. We weren’t planning on doing a 2.0.3 release, but then we discovered the CLR folks made a breaking change to partial trust in Windows 7. David recently emailed the IronPython mailing list looking for feedback on other must-fix bugs we can get to for 2.0.3. If you’ve got an opinion on 2.0.3 must-fix bugs, please respond to that thread.

For 2.6 service releases, we’re looking to tighten up the timeframe a bit from last time. We’re planning to ship service releases of 2.6 in December and February. However, since we don’t have a major release ship vehicle in the 2.x branch until Python 2.7 next summer, these service releases may contain new functionality in addition to bug fixes. In particular, we will look to include any missing modules work that I discussed in my RC announcement post in these service releases.

In addition to the IronPython 2.6 service releases, we’ll also continue to track the Visual Studio 2010 beta cycle as it heads to RTM. I can’t comment on VS2010 dates, but I can say that we will ship a CTP of IronPython 2.6 for .NET Framework 4.0 for Visual Studio 2010 Beta 2 and that we are committed to shipping the RTM of our .NET 4.0 version the day that Visual Studio 2010 is publicly available. Given that dynamic the big new feature of C# 4.0, we want to make sure IronPython is ready to go as soon as C# 4.0 is available.

BTW, we are well aware that “IronPython 2.6 for .NET Framework 4.0” is a long ugly name. Any suggestions on a different one? We’ve been thinking “IronPython 2.6 R2” since the “R2” nomenclature is big around here. But “R2” doesn’t really capture the essence of the .NET 4.0 compatible release. Besides, when has the dynamic languages team at Microsoft ever done ANYTHING because it was popular with the Microsoft marketing folks? 😄

At this point, we’ve got the next few months mapped out, but not much more beyond that. Specifically, we have two gaping holes in the roadmap:

• Visual Studio Integration
• IronPython 3.x

For now, I’m going to leave these holes unfilled. Currently, the rest of my VS Languages teammates (along with the rest of DevDiv) are heads down driving towards beta 2 of Visual Studio 2010. Once they reach that milestone, planning on Visual Studio v.next will begin. Those plans have the potential for impacting how the IronPython team proceeds going forward.

Frankly, several members of the dynamic languages team have been pitching in with the “drive to beta 2” effort so we’re a little more short handed than usual. If we get those people back, then we’re in a much better position to execute on both VS Integration and IronPython 3.x. If we don’t, then we have to make some hard choices about how to proceed. I’m guessing most would agree that VS integration is more important IronPython 3.x support. However, those aren’t equal efforts by any stretch of the imagination. How valuable is VS integration if, for example, we don’t have the bandwidth to build decent intellisense? As I said, hard choices.

If you want to make your voice heard on Microsoft’s level of commitment to IronPython, make sure you go rate the IronPython integration issue on Microsoft Connect. (while you’re there, rate the IronRuby integration issue too.) The IronPython integration is currently the top rated open issue on the VS Connect site and is the second highest vote getter out of all the Connect issues (active or otherwise) logged since VS 2010 shipped it’s first CTP! ¹

We released the IronPython 2.6 release candidate on CodePlex yesterday. If all goes well, this will be the ONLY RC and we’ll republish it as the RTW build in about a month. So if you’ve been holding off on experimenting with the 2.6 release, now’s the time to jump in with both feet.

As I’ve written before on this blog, this is a HUGE release for us:

• Python 2.6 features such as with statement, class decorators and byte literals
• Adaptive Compilation
• __clrtype__ Metaclasses
• ctypes and Frames support
• Lightweight Debugging
• 417 bugs fixed!

Anyway, with 2.6 winding down, the IronPython team finds ourselves in a unique position that we’ve never been in before: caught up. As far as I can tell, most of the Python community hasn’t made the move to Python 3.1 and Python 2.7 is looking like it will be released next summer. So IronPython is caught up with the latest version of Python most of the Python community appears to be using.

So that begs the question: what do we do now?

Of course, we want to hear from you regarding our next steps, but some things we are looking at include:

• .NET Framework 4.0
  We’ve shipped CTP releases of IronPython for each public beta of Visual Studio 2010 and  .NET Framework 4.0. You can expect that to continue as Visual Studio 2010 winds down and ships.
• Fixing Bugs
  417 bugs fixed is good, but there are still 839 active work items in our issue tracker. In previous releases, we’ve done minor bug fix releases every few months so we’ll probably keep up that cadence. Make sure you go vote for bugs you think are important.
• App Compatibility
  One thing we can do is take some of the more popular Python apps such as Django and Mercurial and make sure they run well on IronPython. In some cases, there may need to be changes to the Python apps to get them to run on IronPython (for example, see Jeff Hardy’s patch for running Django on IronPython) which assuredly means more time with lawyers for me.
• Missing Modules
  While IronPython 2.6 is our implementation of Python 2.6, there are binary modules we haven’t implemented yet like _csv, _ast and pyexpat. You could consider this App Compatibility work, but we have a different internal process for bug fixing and implementing new features so I broke this out separately.
• Documentation
  Invariably an area for improvement in all software, our doc story today is pretty much “go look at docs.python.org”. Of course, that doesn’t cover any IronPython specific functionality. Of course, what would be great would be to combine existing Python docs with IronPython specific docs in a single reference, which also assuredly means more time with lawyers for me.
• Tutorials
  If you haven’t seen Michael Foord’s Try Python, it’s awesome. However, it was recently pointed out to me that it doesn’t include any IronPython specific behavior (importing and interoperating with .NET types for example). The IronRuby Tutorial has specific IronRuby features and it would be awesome to do the same for IronPython. Of course, if we wrote new tutorials in reStructured Text, then I’m guessing it would be easy for Michael to include it in Try Python via his rst2xaml tool.
• “Just Text” in Silverlight
  If you haven’t seen MIX Online Labs Gestalt project, browse to one of the samples and View Source. Python as “just text” in the browser. Cool, eh? Jimmy is working on implementing the “just text” model for the Silverlight version of IronPython (and IronRuby).
• Visual Studio
  There’s no work item for VS Integration in our issue tracker, but there have been 112 votes for IronPython integration (as well as 79 votes for IronRuby integration) in the VS 2010 connect bug database. No promises here, but we are acutely aware of how popular this suggestion is.
• CodePlex Foundation
  The CodePlex Foundation is a new non-profit foundation sponsored by Microsoft with the explicit mission “to enable the exchange of code and understanding among software companies and open source communities.” As one of the oldest open source projects at Microsoft, we are very interested in the CodePlex Foundation as you might imagine. However, CodePlex Foundation is VERY new – everything is tagged “interim” for the first 100 days. Once the Foundation elects non-interim board members and establishes things like a charter and by-laws, you can be sure we’ll be investigating it more thoroughly. In other words, definitely more time with lawyers for me.

In case I haven’t said it lately, it’s great working on the IronPython team with Dino Viehland, Dave Fugate and David DiCato (The IronRuby guys aren’t bad either!). Also, I may whine about the amount of time I spend with lawyers, but honestly Yong, Kathryn and Kevin – our main LCA contacts – do a great job helping us figure out how and where to push the envelope so thanks to them as well.

I’ve been back from Denmark for a week – it took me that long to get back on Pacific time zone and dig out from the mountain of email that collected while I was gone. But I got word from my esteemed host Martin Esmann that the video of my TechTalk had been posted to Channel 9, so it seems as good a time as any for my trip report.

At each of these universities, I did two talks. The first was Pumping Iron: The State of Dynamic Languages on the .NET Framework. That’s the one in the Channel 9 video. The other talk was Developing with the DLR, which I’ve posted to my Skydrive. That talk was more focused on the CLR and DLR as a platform for language development. If there’s interest (leave a comment), I’ll record audio for that presentation and post it up on SlideShare or something like that.

Aalborg University

First stop of the University Tour was Aalborg University – about a four hour drive from Copenhagen (or as the Danish spell it København). As you can see on the map, we started with the furthest university away then worked our way back to Copenhagen. Martin picked me up at the airport and we hit the road. I was horribly jet lagged, but we spent most of the drive geeking out about programming languages (when I wasn’t napping).

Each of the universities had a different focus that I was interested in. At Aalborg, it was in teaching programming. Given the popularity of Python in education, we had lots to talk about. My host at Aalborg was Bent Thomsen who has done significant research on this topic, as has his wife Lone. One of the areas we discussing in particular was about teaching classes vs. objects first. Apparently, these days there’s significant momentum behind teaching class first, but the folks at Aalborg – as I understand it – have seen that approach has been ineffective. That squared with a talk I saw on teaching OOP with Python that I saw last year at PyCon by Dr. Goldwasser.

The other area we discussed was teaching compiler design. Clearly, this is an area I thought the DLR could be a big help in. Bent primarily uses Programming Language Processors in Java to teach this course, but he finds that it’s a little out of date + he’s much more interested in the compiler aspect than the interpreter aspect of that book. The idea of generating DLR Expression Trees which can be compiled into IL with a simple call to LambdaExpression.Compile and can then run directly on the CLR seemed to sound appealing to him.

Aarhus University

Next up was Aarhus University. I didn’t get to spend as much time with the folks from Aarhus, though our host Olivier Danvy did help me find a “uniquely Danish” gift for my wife (though I also brought her Danish bread & chocolate). We spent some time talking about F# and compiler design, and Olivier made this great comment over lunch that “OCaml is a domain specific language for compiler writers”. That is very true.

Olivier had to leave for a previous engagement, so Jan Midtgaard – who teaches Aarhus’ Compilation class – hosted me for the actual talks. In that class, they implement a subset of Java known as Joos in AspectJ. One of the cool things about this class is how they grade the compilers – you upload your complier code to a web site and they run it against an existing test framework. They couldn’t give the students the test framework directly because it would be too easy to reverse engineer the tests from the compiled Java code (I assume the Java world has the equivalent of Reflector?) Like Aalborg, I spent significant time discussing the idea of targeting the DLR in their compiler class.

University of Southern Denmark

Of the four universities I visited, this was probably the poorest fit for the content I was delivering. On the other hand, it was awesome – USD has a strong focus on Robotics. They even have a RoboDays Robot Festival in Odense. Unfortunately, the festival was the weekend after I visited, so many of the robots were out in preparation for the festival. However, our host Ulrik Schultz did bring us to to visit the Modular Robotics Research Lab so I got to see these guys in action:

Real transforming robots! Not quite Optimus Prime mind you, but you gotta start somewhere. These robots are call ATRON and they’re pretty impressive to see in action. However, they are kinda weak computationally – they only have 128k of flash memory + 4k of ROM. 4K! However, the next generation of these bots is supposed to have like 64MB of memory and a FPGA – more than enough power to use the the Micro Framework.

University of Copenhagen

The final stop on my university tour was University of Copenhagen, where I was hosted by Fritz Henglein of the Algorithms and Programming Languages Group. He’s done some research on dynamic languages, but these days he and his team are doing some fascinating research on the intersection of business and programming languages. He leads a project called 3gERP in partnership with Microsoft Development Center Copenhagen to “develop a standardized, yet highly configurable and flexible, global ERP system for SME’s based on fundamentally new software architecture.” That topic isn’t as interesting to me in my current role in the VS Languages team, but was very relevant to my background in services architecture and MSIT.

Copenhagen .NET Users Group

While I was in Denmark, I got to speak to the local .NET users group about IronPython. These are always fun since they are less formal. Also, this was a much more .NET knowledgeable crowd than I had had all week so I got some deeper questions about the .NET stack. Among the members of that user group is Mads Kristensen, founder of the BlogEngine.NET project. So I put together a special demo “integrating” IronPython into BlogEngine.NET. It was kinda silly – I wrote an extension that would execute any blog post as python that was in the RunPython category. But it was also mind-numbingly simple:

[Extension("Extend .NET Blog Engine with IronPython")]
public class IPyExtension
{
    static ScriptEngine _engine;

    static IPyExtension()
    {
        _engine = IronPython.Hosting.Python.CreateEngine();
        Post.Serving += new EventHandler<ServingEventArgs>(Post_Serving);
    }


    static void Post_Serving(object sender, ServingEventArgs e)
    {
        Post p = (Post)sender;
        bool runpython = p.Categories.Exists(delegate(Category cat) {
            return string.Compare(cat.Title, "RunPython", true) == 0; });
        if (runpython)
        {
            e.Body = _engine.Execute<string>(e.Body);
        }
    }
}

I’d love to see REAL IronPython integration into BlogEngine.NET, but I needed something I could do in a couple of hours late at night in a code base I wasn’t familiar with.

Pumping Iron TechTalk

Finally, on Friday I delivered my final talk of the week, which is available to watch and download from Channel 9. It was a packed house and I was a little nervous about having the talk recorded, but I think it went well. Certainly, it seemed well received by the audience.

I ended the work part of my trip to Denmark with an interview with a Danish IT newspaper (which I’ll post a link to when it gets published) and a sit down with the Dyanmics:NAV team. My wife always tells me that she’d love it if I got a 6-12 month assignment to work overseas, so I tried to convince the NAV team that they REALLY want to integrate IronPython like the Dynamics AX team is doing. If you see a post here about me moving to Copenhagen, you’ll know I was successful! 😄

Final Thoughts

Other than the jet lag, which seemed tougher on this trip than when I’ve gone westward to New Zealand, Australia or Malaysia, I had a blast. It was a real treat seeing so much of Denmark and getting to talk to so many interesting people. I even got to do some sight seeing in Copenhagen and Odense. Hans Christian Andersen was born in Odense and so I got to see the house he was born in as well as get my picture taken with this statue of him right outside our hotel. Major thanks to Martin Esmann for inviting me, driving me around – we drove a megameter, aka 1000km, over the course of the trip – and being an all around amazing host.

Christian Weyer makes a great comment on yesterday’s post about the barbarian rediscovery of async messaging:

But how do these two toolkits solve the NAT/Firewall issue? Without a solution to this they are pretty much useless in breadth usage.

Simply put, they don’t. Frankly, they don’t even try. And I agree with Christian that the NAT/Firewall issue makes any async messaging based approach useless for clients. It’s kind of like the last mile problem in the telco/cable industries – you’ve got this great capability in the center, but you can’t leverage its full potential because of the massive effort it takes to push that capability all the way to the edge of the network.

Dave Winer has been pretty explicit with his RSS Cloud work: “The goal is to have a Small Pieces Loosely Joined equivalent of Twitter.” PubSubHubbub doesn’t mention Twitter by name, but the protocol spec specifically says “Polling sucks. We think a decentralized pubsub layer is a fundamental, missing layer in the Internet architecture today”. Both specs have a fundamental design that looks like this:

This picture leaves out multiple publishers and subscribers and the subscriber registration process, but you get the basic idea. And it all works great assuming that both the subscriber and the pub/sub infrastructure can accept incoming connections. While that seems like a fairly safe assumption for infrastructure pieces, it is clearly a faulty assumption for any subscriber running locally on a client machine. Client machines primarily live behind firewalls at the office, behind NAT routers at home or on mobile wireless network – all of which disallow most if not all incoming connections. In other words, this works just fine for server subscribers (like, say Google Reader) but not for client subscribers (like, say TweetDeck).

As far as I can tell, the only way to enable client subscribers to play in this async messaging world is via some type of relay service. Any other solution I can think of depends on mass adoption of new technology, which as I mentioned in my last post is nearly impossible.

In this approach, the client subscriber makes an outbound connection to some type of relay infrastructure, which in turn creates a endpoint on the public internet for that client. Registration for pub/sub happens as normal, using the relay endpoint as the notification URL. Then, when a message arrives on the relay endpoint, it’s sent back down the outbound connection to the client.

The relay approach is technically feasible – it’s used in many places today. Exchange DirectPush uses this approach to support real-time delivery of mail to mobile devices – though the relay capability is built directly Exchange client access servers rather than available as a separate service. The .NET Service Bus – part of Windows Azure – provides a hosted relay infrastructure that anyone can leverage (though their support of non-windows platforms is pretty weak). I haven’t worked with it, but it looks like Opera’s new Unite platform includes a relay service as well (note, they call it a proxy service). Nice thing about Opera Unite is the async messaging infrastructure is built right into their browser, though you could achieve something similar in any browser using Flash or Silverlight.

Yes, having to relay messages sucks. But the question is, which sucks worse: polling or relaying?

At PDC 1996, Pat Helland did a six minute bit where he compared personal computing to the sacking of Rome and Microsoft Transaction Server to the Renaissance. It was called “Transaction Processing and the Barbarian Hordes” and in my opinion it should be required viewing for everyone in the tech industry.

Of course, the tech industry has changed significantly since PDC96. In particular, personal computing has become the new “Classical Rome” and web developers are the new barbarians. Just as Microsoft rediscovered transaction processing in the 90’s, it seems that RESTifarians are on the verge of rediscovering asynchronous messaging.

“The internet has been dead and boring for a while now.  It has reached a point of stability where flashes of technological creativity are rare, but every now and then some new technology can put a spark back in the ole gal (no sexism intended).

If you haven’t heard of WebHooks orPubSubHubBub its about time you did. Both are designed to  simplify and optimize the web.”

Mark Cuban, The Internet is about to change

Not to put too fine a point on it, but these “flashes of technological creativity” that Mark’s going gaga over aren’t new at all. Both Web Hooks and PubSubHubbub are essentially async messaging, the oldest form of messaging in the history of networking. But just as personal computing ignored the importance of transaction processing for a long time, REST has long ignored the importance of async messaging. Instead, web development has instead been focused exclusively on request/response – something I’ve struggled with for quite some time. But the rise of Twitter has driven many people to realize that something I’ve known since 2003: “In order to truly evolve syndication…we need to break free of the synchronous polling model.” ¹

I love the slogan from this Web Hooks presentation: “so simple you’ll think it’s stupid”. Web Hooks aren’t stupid – far from it – but they certainly are simple. They’re basically callbacks – which Web Hooks creator Jeff Lindsay readily acknowledges – invoked across the network using standard REST technology like HTTP and XML or JSON. The canonical webhook examples are Paypal Instant Payment Notification and GitHub Post-Receive Hooks. In both cases, you register a custom notification URL with the system in question. Then, when something specific happens in the system, a message gets POSTed to the registered URL. In some scenarios, it’s a simple notification. For example, when GitHub receives a commmit push, it POSTs a JSON message about the commit to the registered URL. In other scenarios, the initial message is the start of an async conversation – the system expects you to POST a message back to them sometime in the future. For example, when a customer makes a payment, PayPal POSTs a message to the URL you registered. You then confirm the payment by posting a message back to a well known PayPal URL.

Note, by the way, that both of these canonical examples depend on async messaging. GitHub isn’t going to do anything with a response anyway, so there’s no point in sending them a response. PayPal, on the other hand, is expecting a response. Yet, they use async messaging instead of an arguably simpler HTTP request/response operation. They do this for same reason WS-Transaction is the Anti-Availability Protocol – the last thing you want to do is lock up precious resources in your system waiting for some nimrod on the other side of the Internet to respond to a request you sent. Instead you what PayPal does – send an async message, listen on a separate channel for a response, correlate the messages explicitly via some kind of conversation identifier and release your precious resources to do other work while you wait for the response.

As for PubSubHubbub, it’s focused on real time delivery of new information. Dave Winer’s recent RSS Cloud efforts focus on real-time notification as well. In both cases, instead of subscribers polling a given RSS feed for changes every X amount of time, they register for notification when the feed is updated. This is very similar to the way GitHub uses async messages for commit push notification as described above.

Both PubSubHubbub and RSS Cloud include an intermediary that’s responsible for managing the list of current subscribers and relaying the notification when the publisher makes a change.  Honestly, I’m not a fan of the Hub/Cloud intermediary – it feels a little too ESB-like to me. However, since it’s only relaying notifications it receives without transformation, I can live with it. Besides, there’s no reason why a publisher can’t act as it’s own hub. The vast number of blogs and twitter users have so few subscribers that the extra layer of abstraction is probably not worth it. On the other hand, if you’re going to run a notification hub for the largest users, you might as well use it for smaller ones as well.

While I think Mark’s laid the “new technology” hype on pretty thick, I do think he hits the nail on the head regarding the major new business opportunities that can come from adopting the heretofore ignored async messaging model on the web:

“This could be an open door for the content business…Using The Associated Press as an example, AP could post their stories to a HUB. In realtime, the HUB can update member websites so that they will always have information first, before any aggregator. It may not take long for aggregators to recognize the new data on the member sites, but they won’t have it first.

The New York Times could do the same thing. Subscribers could get everything first, in realtime. Then after some delay which might be 1 minute, it might be 30 minutes depending on what the paper thinks is the value related to timeliness, it could post on the website and on twitter and facebook as updates. Would NY Times online readers pay $1 a month to be guaranteed that they get their news first, before anyone else ? I dont know.

In the sports world, text based play by play websites could be updated in realtime rather than pulling every 30 seconds or requiring the user to hit refresh every few seconds.”

Arguably, this opportunity is easier to realize precisely because async messaging isn’t new technology. Getting people to adopt a new technology is incredibly hard. It’s much easier to get people to adopt a new pattern for using an existing technology. And async messaging has been possible as long as the web has been in existence.

Web Hooks and PubSubHubbub are long overdue but very welcome steps forward in the evolution of the Internet. I wonder what the barbarians will rediscover next?