Between PDC and now, I was in Redmond on Monday and Tuesday at a meeting with the Indigo team. One of the topics discussed were the new transaction management capabilities that are part of Indigo (which, for Longhorn, includes a lightweight transaction manager).

Ingo was there, too, and we had a little argument about how hard it is to write transaction resource managers. Ingo thought that it would be awfully hard to write them and that average programmers would never do so and wouldn’t see the need for them. I said “hey, it’s really trivial”, explained that I consider transactions a very general programming paradigm for much more than just databases and told him that I would write a little demo to prove it. I wrote the demo on the plane going home in about 3 hours. Here it is.

The “2 Phase Commit Puzzle” application is a little Windows Forms puzzle that doesn’t use Indigo or the Longhorn bits, but rather employs a little lightweight 2PC transaction manager that Steve Swartz and myself hacked up when we were on our Scalable Applications tour this spring.

The puzzle uses four resource managers (transaction participants). The TileWorker keeps track of the tiles as they are moved around, always votes “yes” on Prepare, does nothing on Commit and rolls all tiles back into their original (shuffled) state on Abort. The TimeoutWorker votes “yes” if the puzzle is completed (pressing the “Done” button) within the preset time-span and “no” otherwise. It does nothing on either Commit or Abort otherwise. The GridWorker votes “yes” on Prepare if the puzzle is completed (order is correct) and otherwise “no”. It also does nothing on Commit or Abort. The OutcomeContingentMessage is a participant that will always vote “yes” on Prepare and shows a “Congratulations” message on Commit and a “You failed!” message on Abort.

The great thing about this little puzzle is that I could add arbitrary other success/failure conditions for the outcome of the puzzle (e.g. number of moves) without having to rewrite or even touch the code determining the other conditions or the code emitting the result message. I would just have to hook in the new resource and feed it with information from the grid.

Transactions aren’t just for databases. The discussion of the theory behind this is of course in our already well-known transaction deck.

Below are the download links to the game executable (in IE, you need to right-click and save it to the local disk; it will not work if started directly from IE) and the source code archive, including the simple WorkSet transaction manager. Check it out.

The typical PDC attendee is very special. PDC is not like TechEd where you get very practical information on today’s shipping products. PDC is about futures and it requires a lot of imagination of how applications could look and could work on the new platform. It’s about building excitement for the things to come. PDC attendees are the folks who will make the first wave of applications happen. They are excited about technology and they love to code.

Don Box’ talk yesterday afternoon (WSV201) was very much about now. I heard a few people complain that he didn’t show enough new code. I don’t think he should have. I found his talk very important and Don delivered his message very well. Don’s talk was very much about architecture. No matter how much you want to see code, it’s not the 1990’s anymore. Simply hacking up an app won’t let you play in a connected application ecosystem that’s powered by Web services. WinFX will enable better applications by simplifying coding complex applications in a big way and making developers more productive. You’ll code less. Code isn’t all that matters. Architecture matters. Negotiation and contracts matter. Design matters.

There were four key takeaways from his talk: Boundaries between applications are explicit. Indigo’s programming model is different from previous distributed programming models such as COM and Remoting, because it doesn’t make objects implicitly remote. You need to declare things as being remote. The fact that you’re theoretically able to write a local application and can then write a configuration script that distributes this application across multiple machines using Remoting was a naïve approach. Likewise, writing a COM application that’s built as a local application and reconfiguring it to run as a distributed application using a different registry setup is a naïve approach. With Indigo, you will need to start writing applications explicitly as being remote. If you love objects, you will find a few things very restricting in this world, and at first sight. There are no automatically marshaled callbacks, interfaces and objects. There are messages, not object references going across the wire. The endpoints of communication, called services, aren’t fragments of the same application based on the same types and classes. Services are autonomous units which adhere to compatible data contracts and policy, not dependent units that use identical implementations. We share schema, not type.

Don recommended, as I’ve done earlier here on the blog, one of the most important Indigo talks for anyone who’s building software on today’s platform (that means: everyone at PDC): WSV203, “Indigo”: Connected Application Technology Roadmap; Wednesday, 11:30am, 409AB.  Go.

I’ve got the PDC build running on my box. Jim Allchin was right; it isn’t exactly screamingly fast – at least in Virtual PC. Here are a few notes:

·         Needless to say, but: Have a dedicated box for Longhorn or use Virtual PC. I’ll likely get a new box when I am back at home. Sounds like a machine brutally optimized for 3D gaming is a good bet – along with 2GB of memory.

·         If you can’t at least assign 256MB of memory to the VPC machine, forget it. If you can allocate more, go for it. Shut down all apps and services on the host you can and give Longhorn room to breathe.

·         The VPC2004 from the PDC disks will remove any previous Virtual PC builds from Connectix. The version from the PDC disks will expire February 28^th, 2004. Which means that I just went from a licensed copy to a demo copy. I don’t like that, at all.

·         You will need to log on to the windowsbeta.microsoft.com server to acquire your product key. The userid and password is in the disk booklet.

·         Take your time. Installing into Virtual PC takes a very long time. Expect that your box will take about 2-3 hours and I wouldn’t do too much on it during that time. Expect the box to lock up, requiring a hard reset. It did that several times for me.

·         I’ve mounted one of the ISO images from Disk 2 into VPC, which seemed to be the most convenient option.

·         On my Dell Inspiron 8100, Longhorn comes up in 4-bit color mode and that’s the only mode available. You will have to install the VPC additions into Longhorn to get a graphics driver that works, reboot and then switch to that one.

·         Just right after install, with nothing done, the VPC disk size stands at 3GB. I think you should have some 6-10GB available if you want to do anything with it but looking.

Here’s my quick, two sentence definition of Indigo in order to give you an idea about the scope of this thing:

Indigo is the successor technology and the consolidation of DCOM, COM+, Enterprise Services, Remoting, ASP.NET Web Services (ASMX), WSE, and the Microsoft Message Queue. It provides services for building distributed systems all the way from simplistic cross-appdomain message passing and ORPC to cross-platform, cross-organization, vastly distributed, service-oriented architectures providing reliable, secure, transactional, scalable and fast, online or offline, synchronous and asynchronous XML messaging.

I am somewhere above Canada right now, on board of the KLM 747-400 named „Seoul“ (Reg. PH-BFS), which is flying in a passenger/freighter configuration from Amsterdam to Los Angeles today. My seat is 74J, which is on the upper deck. It’s always cool to fly on the upper deck of a 747, regardless of class. Some airlines, like British Airways, use the upper deck for economy class, some, like KLM, seat their business class there and others, like Lufthansa, their first class. Today, wines are great, food is excellent, and the service staff is very friendly (and eye candy) on Holland’s national airline.

Tomorrow, PDC03 starts. Cool. Can’t wait to see my friends, can’t wait to see what’s new. This is Christmas Eve for Windows development geeks.

newtelligence dasBlog v1.4: After you have read the release/upgrade notes, get it from here.

I have done a bit less testing than I usually would, because I wanted to get this version out in time for PDC – just because I want to have some of the new features (especially cross-posting) for myself for PDC. I have bravely deployed this new build on my own blog (here) and it didn’t break me, so it should work for you as well. Make a backup of your site before you install, ok?

Cross-posting is certainly the coolest feature if you happen to have two or more blogs (the number of folks who have that is growing daily). Before I add a formal explanation to the docs (which isn’t going to happen tonight) here’s a quick primer:

If you have cross-posting enabled on the configuration page, you will have two more entries in the administrator bar. “Crosspost Referrers” and “Crosspost Sites”. Crosspost sites is an editable list where you can enter the other blogs you want to post to and where you want to keep entries synchronized. The picture shows my setup for Lonnghornblogs.com. Hostname and Port should be trivial to understand. The “Endpoint” is the Blogger API or MetaWeblog API endpoint of your blog engine (leading forward slash required). It’s tested that dasBlog interops with itself ;), with .Text and Blogger.com. There’s not much of a reason why it shouldn’t interop with more engines. The API type is either “Blogger” (for Blogger.com) or “MetaWeblog” (for mostly everything else, including dasBlog and .Text). Click the “Test” button to verify the setting before you save them.

Once you’ve set up one more more sites, you’ll get the following little extra box at the bottom of the “Edit Entry” page:

Just check the sites you want to cross-post to. If the site supports the MetaWeblog API, you can also enter categories there. Multiple categories are separated by semicolons. Once you post, the cross-posts are queued up and will be posted within a couple of seconds. One catch: You should no re-edit the entry before the synchronization is done; typically within 15 seconds after your post has been stored. If the entries haven’t been synchronized, yet, the checkboxes will remain unchecked.

If you subsequently edit the entry, the changes will be replicated into the foreign Weblogs (not vice versa). If you delete the entry, the foreign entries will also be removed. In essence, you only have one blog to maintain, but multiple publishing points.

The feature isn’t yet integrated with Mail-To-Weblog. What you need to do there is to post your entry via mail, edit the entry later via the web interface and change nothing except checking the appropriate boxes and setting the categories. Support for cross-posting via Email will be in v1.5.

The “Crosspost Referrers” page shows the referrers that you are getting on the foreign site. Note: Your main blog is going to get some of the traffic of the foreign blogs because of the referrers feature. The referrer stats are baked into the cross-post feature and can’t be switched off singly at this time. For each unique hit the foreign site gets on one of your entries, there’s a potentially a request for a 43 byte image plus a bit of protocol overhead; let’s make that 100-150 bytes. Keep that in mind before you enable cross-posting to a high traffic site, otherwise this feature may end up “slashdotting” your own server. (Similar considerations are true for “Aggregator bugging” – see the release notes)

PS: Thanks to all the heroes in the GDN Workspace who helped a lot with this release.