I saw Brad's post entitled The Love Affair is Over which is a response to the announcement of support for generics being added to the CLS 2.0 and wanted to chime in. In Brad's post he mentions that James Robertson shares the same opinion. It seems to me that James has confused CLS (Common Language Specification) and CLR (Common Langauge Runtime), a common misconception, but I'm just not sure if Brad is doing the same or if he just doesn't like the fact that the proposed CLS rules regarding generics are so weak.

What's the big deal with the CLS not supporting 100% of the features of generics that are available in the CLR? This only becomes an issue for languages who don't (yet) have a full knowledge of generics. If you're not even trying to interop with them (i.e. writing in C# and VB.NET only), then who really cares? As an example today, the unsigned types are not CLS compliant. Yes it sucked that stuff like FileInfo::Length, which can obviously never be negative, has to be a long instead of ulong, but hey we somehow managed to get by. Now consider that generics are far more complex than that and I think it's fair to not force 100% support for them into the CLS.

As I said in my comment to James' post:

... granted it would be great to say "all languages built on CLR 2.0 must support all features of generics!", but... one step at a time. The fact that they even came out with any kind of CLS spec around generics should be considered a win.

So who does this really affect? Two groups of people of people as far as I can tell: a) the language implementers who do not want to support all features of the CLR, but want to play somewhat nice with the other kids in the sandbox and b) the people who choose to use those languages. Surely that's the minority of people developing .NET applications. The solution for those of us using full featured langauges then? Simply don't mark your assemblies with the CLSCompliantAttribute.

Ian Griffiths just posted an awesome entry on animation and the problems related to rendering. I learned a lot reading it, so I highly recommend it to anyone else who is into this subject... which should pretty much be anyone who is going to be building applications with Avalon. ;)

Avalon should hide some of the more technical problems such as frame rate and tearing from us, but the other topics Ian talks about are very much up to the developer/animator to understand and solve.

Ok look, I'm not exactly thrilled with the fact that WinFS might not see the light of day until ~2010 either. I've been looking forward to the point where rich forms of data are managed by the OS for quite some time. Imagine being able to ship a product where you don't need to install a custom database solution? Imagine users being able to relate data from your application to data from any other application (and vice vera) ever written? Imagine being able to tag any data with your own metadata using the shell instead of the vendor having to build something into each of their own products? Finally, imagine being able to search all that data, regardless of what it is, in a heartbeat? Those are the promises of WinFS.

Now the funny thing is that the Longhorn client previews that have been released basically contain all of that functionality. So what's the problem then? Why are we going to have to wait so long to get our hands on it? Well the problem is they only really solved the problem for the individual user. The WinFS team, in all the seminars that I ever attended on the technology, always said they didn't have a solution for WinFS on the server yet. They never hid this fact. It was designed as a pure client technology and that was their focus for this release. They intended to add the server aspects of WinFS in the releases of Longhorn server which, if memory of PDC roadmaps serves, wasn't going to be released until ~2007. Obviously all these dates have slipped now by a couple of years, so ~2010 really isn't that far off.

The problem with anything beyond a stand alone client solution is as follows: Imagine if I create a contact. Then I associate a whole bunch of random data, via WinFS relationships, to that contact (i.e. Emails, Word Documents, Joe Developer's custom application data, etc.). All the data and metadata are stored in my client WinFS store. I can now search, chase down relationships, relate more data and everything is great. Now, what do you think happens if I try and copy that contact to a shared WinFS store on a Longhorn server? What do you think should happen? This is the scenario that is currently undefined. If you think about it, it's definitely not an easy problem to solve.

• Should all the related data be copied as well?
• Should links be created back to the related data streams on the client machine?
• What happens if I want to view a document related to the Contact on the share then and the client isn't connected to the network right now?
• Do you force an item and all of its related items to live in a single WinFS store?
• If the data is distributed, should we search all the related data in satellite WinFS stores to find out if that Contact is in any way related to the search phrase “Acme sales pitch” which may be defined in one of the linked/related data documents?

Now, these questions may seem technical, but take your geek hat off for a second and you'll realize there's a serious usability aspect to each one. Each changes the user experience and the way people work with the data. This is the issue that I think most people are overlooking here. The technology is the “easy” part folks, it's solving the user experience that is the challenge here. If every machine was an island WinFS would work today as evidenced by it's existence in the Longhorn client previews. Since Microsoft got pushback from the community when they didn't have an answer for the server side, they decided to delay the release until they could solve the whole story. Yes, you heard that right: it was us who caused this delay. Maybe not the small application developer, but the big companies who basically gain no benefit from WinFS stores being islands since their thousands of users often need to work on the same data with other users. If I can't store related data together and then have another user in my organization look at that same data with the same relationships and metadata, then what's the point from a business value add perspective? Hint: there is none. That's why we're not gonna see this technology until all these questions are answered.

All this said I of course agree there are technical hurdles. Yes the performance we see in the Longhorn client drops is far from usable. There is also the challenge of row level security which even Microsoft's flagship SQL Server 2005 still lacks. Scalability of the technology in the instance of a huge, corporate WinFS store may be an issue. I could go on, but, as I've already stated, these are technical issues and I have complete confidence that the combined brainpower of Microsoft's WinFS team can overcome all of them in less time than it will take to consider all the ramifications of the decisions they make up front about how we will work with our data for the next ten to fifteen years of our lives.

I seem to remember thinking Indigo was one of the most complete pillars of Longhorn when I walked out of the PDC 2003, where as Avalon had a lot more work to go. Since then I think I believe I recall reading that they were taking some Indigo pieces back to the drawing board, but... it's been a while. Now that we've had an Avalon drop, is there an Indigo drop on the way anytime soon? I love playing with Avalon, but it's a hobby. More important to my every day work is how I will be writing services with Indigo, so I'd love to get my paws on that as soon as possible.

So, can we expect an Indigo drop anytime soon? :)

I just noticed I can't find any documentation on ServiceManager, IScopedService, etc. in the WinFX SDK. It looks like all the Annotation Framework classes are all marked as obsolete as well. I thought the Annotation Services were an awesome idea. John Developer can just add this feature to his application with very little work on his end. Not only that, but it's basically the poster child for the power of providing generic services to Avalon apps.

Is the whole architecture getting dropped? :(

Joe Marini just made a post titled “When Secrets Make Sense”. Personally I think he's dead on. How can you even argue that point? If I rolled out a product that solved a problem or set of problems that nobody else out there has solved, why in the hell would I tell everyone else how to solve it by giving out my source?

Let's see, the financial success of my business and it's hardworking employees is based on the success of this product and the fact that I've solved said problems makes my product the number one, must have piece of software for a target audience. My options are: a) Give out the source code (effictively enabling any other company to implement the same features which we've invested time and money on solving), make no where near the same profit and tell all the employees their holidays won't be as fruitful this year or b) Protect my intellectual property, profit from my success and give everyone a nice holiday bonus. Hmm... tough one. :)

Ok enough sarcasm. Usually the argument that comes with OSS is that you can make the money on support and other services. Believe me, I know there's money to be made on services. In fact, my company is a service and that's the only thing we make money on. Software for Mimeo is simply an enabler. We've never made a dime of off anything I've ever written... errr directly that is! ;) All the money is made in brick and mortar print services. However, in Joe's case, the company was selling the software and their entire business revolved around it. Sure you can sell support and services for the software, but if some other company or, worse, several companies were able to implement the same feature because you released your source code, that's a huge chunk of profit that you just gave up. Those other companies can offer support and services too. While you can certainly gain an edge with support and services, that edge will never be anywhere near the edge you can gain if you offered the sole product that solved difficult problems.

That said, I do believe there's plenty of places where open source makes sense, but end user software just isn't it IMHO. Sure it can it be done, but server applications, frameworks, etc are where open source shines. You can give this stuff away and still make money supporting or providing services around it because your target audience is other companies and developers who in turn are trying to leverage it and turn it into a service for their users.

Avalon introduces the DependencyObject and DependencyProperty classes. At first glance they seem to add unecessary complexity. This article aims to help understand their existance and power.

Update 12/5/04 6:21PM ET:
Per some comments from Rob Releya, I realized that I focused a bit too much on “attached” properties and left out the explanation of why you'd want to use a dependency property even for “simple” properties. I've updated the article with to touch on the “simple” property Canvas.HeightProperty and blended it into the section that segways into the services Avalon can offer around dependency properties. Thanks for the feedback Rob.

(I've also justified the text to make it a little easier on the eyes.)