When web servers were first built, there was a one-to-one mapping between virtual files (i.e. addressable via http) and the physical files (the ones in the file system). Over time, two important capabilities were added. First, the contents of a given file became dynamic. So while you the reader always come back to default.aspx (or rss.aspx as the case may be) the content changes everytime I post something new. Secondly, the physical file dependency was removed. It’s not used much in dasBlog, but in .TEXT this is very prevelant. My last post on blogs.msdn.com is located at http://blogs.msdn.com/devhawk/archive/2005/02/01/364380.aspx. Obviously, there is no actual file named 364380.aspx, .TEXT uses the filename as a key into the DB to find the actual entry content. This technique is used extensively in the new MSDN2 (if you haven’t already, check out Tim Ewald’s MSDN Magazine article about URL design for MSDN2).

So now for the funky idea part – why couldn’t we generate dynamic local files the same way? I’m not sure I’ve got a great use for this yet – most of the apps I use are programmable to some extent, so dynamic content can be generated at the app level rather than at the file system level. But I’m thinking there may be some scenarios where it would make sense to do this at the file system. For example, in the new Winter Fun Pack there’s a new version of the WMP blogging plugin that autoupdates the Outlook and Outlook Express signature files whenever the song being played changes (a la Duncan’s Coding4Fun article). But with virtual files in the file system, you could generate these files when they are accessed instead of writing new ones everytime the song changes, even if Outlook open.

Of course, our local file system typically has more writing activity than the web, so I’m thinking this isn’t that great an idea. But I figured I’d share in case someone else could think of some good uses. Or maybe this already exists and I just don’t know about it.

I just read Dare’s awesome article on C-Omega. If I had any time at all, I’d experiment with it to rewrite dasBlog (well, at least the back end parts of dasBlog anyway). Of course, I don’t have any time at all, so it’s not going to happen (well, at least I won’t make it happen)

Several people have pointed out Herb Sutter’s great article on concurrency entitled The Free Lunch Is Over. When I blogged last week about new possible features of “full-grown” OO languages I mentioned dynamic typing but I didn’t think about concurrency. I think Herb is right: “programming languages…will increasingly be forced to deal well with concurrency” as applications get more CPU bound. Maybe I need to take another look at Comega (or Cw). Cw extends C# in two areas – data typing/querying and concurrency. The concurrency extension used to be called Polyphonic C#, but the name got changed when it merged with Xen/X#. (BTW, there’s a new Cw release (v1.0.2) but no specifics as to changes other than no longer needed VS.NET 2003 to be installed in order to use it.)

Cw adds the idea of asynchronous methods and something called chords – sets of methods with the same method body. The chord method body in only executed when all the associated methods have been called. In the simple buffer tutorial, the buffer class has a synchronous Get method and asynchronous Put method. If you call Get before Put, it blocks until Put is called, then the method body is executed. If you call Put before Get, then the Put call returns immediately (it is async after all) but the call is queued so that when Get is called, the method body is executed immediately. FYI, the Cw docs have a variety of other tutorials of async methods and chords.

BTW, speaking of my post on full grown OO languages…My father suggested that I not jump to conclusions regarding the X-develop‘s support for what they term “toy languages or little domain specific languages”. In fact, Hans Kratz of Omnicore (which makes X-develop) had this to say:

This comment on our website was not intended to bash DSLs at all. Instead we wanted to make clear that the plugin API in X-develop is powerful enough to allow integrating support for “full-grown” languages without placing arbitrary restrictions on language complexity.

For a language developer/integrator this is a plus regardless if he wants to integrate support for a DSL or “full-grown” programming language.

Makes sense. Maybe I was just too sensitive to the use of the word “toy” so close in proximity to “DSL”. Sorry about that Hans.

I saw a post on TSS.NET pointing to the Outlook 2003 Integration APIs:

Microsoft has released former “internal only” APIs for developing applications that work with Microsoft Outlook. The APIs include account management, connection state, free/busy, MAPI-MIME conversion, and the Outlook store.

I have no idea why these APIs have been released at this time, but providing more options/control/tools to developers is better than less – along the same lines of the ASP.NET 1.1 Membership Prototype.

My only issue is that not all the APIs are documented. For example, recently I was interested in being able to progammatically set Outlook’s online/offline status. When I read the post above, I thought the Connection State API would be the answer. Alas, that API can only be used to get notification when the connection state changes. Or, at least, that’s all that’s documented: the IMAPIOfflineMgr interface has seven undocumented methods and the IMAPIOffline interface has two. I’m sure there’s a good reason those others aren’t documented, but it’s frustrating all the same.

Of course, even with the ommisions, that’s a lot of cool stuff to add to Niobe. Simon?

This is just too cool:

You can also use a $w to indicate a parameter.  For example:

@msdn2, http://msdn2.microsoft.com/library/\$w

…and then you can type msdn2 System.String – for the easiest way to lookup classes in the MSDN2 library.

[Simon Guest – Off Topic: MSN Toolbar Suite]