The Mono team is proud to bring you a preview of C# 5.0 a few years before our friends in Building 41 do.

A snapshot of the code is available in the demo-repl.zip file. This contains the csharp.exe C# REPL shell and the Mono.CSharp.dll compiler-as-a-service assembly.

With Today's code drop all those scenarios now work:

• Run Mono's C# compiler on .NET
• Embed Mono's Evaluator in your C# app.
• Use Mono's REPL with the .NET framework runtime.

Update April 28th: I have now uploaded a new version that fixes the bug that people were getting when importing other libraries. Thanks to Marek for the rapid fix.

Background

Although we have had a compiler-as-a-service framework since September of 2008 it has been so far limited to Mono users, which effectively means only Linux and OSX users could use our C# REPL and the compiler as a service.

The reason is that the Mono's C# compiler uses System.Reflection.Emit as its code generation backend. This API was fine for implementing C# 1.0 but required a few changes to support compiling its own core library (mscorlib, the equivalent of libc in C or rt in Java).

When we started to work on our C# 2.0 support, we were working on our compiler as the language was being standardized at ECMA. Our compiler evolved faster than the underlying support for Reflection and Reflection.Emit did and this lead to more Mono-specific extensions being added to our Reflection and Reflection.Emit code. The more extensions that we depended on, the fewer chances we had of running with Microsoft's runtime.

As time went by, Microsoft did improve their System.Reflection.Emit, but at that point, it was too late for us to go back to it.

This had the unfortunate side effects that our compiler could not run on the Microsoft runtime. Now, this per se is not a major problem since Windows users likely use Microsoft's CSC compiler.

But this also meant that our awesome compiler as a service could not be used by .NET developers and it also meant that our REPL shell could not be used with .NET and most importantly, neither one would run on Silverlight.

Our compiler also relied heavily on our extended System.Reflection and System.Type as its own type system. And we could not just change our APIs for Microsoft's APIs to run on the Microsoft runtime.

Today's commit at the coref replaces our dependency on System.Type and introduced our own Mono.CSharp.TypeSpec which lifts many of the restrictions that we had on System.Type. All of the hard computations that we had to do for inflating generics types are done here now and we can query the types without the backward Reflection limitations.

With today's changes, not only we became more portable, but the move from System.Type to TypeSpec and MemberCache improved the compiler performance by 30% and fixes dozens of bugs that were very hard to fix with the previous compiler architecture.

REPL Love

We have a small guide on using the C# REPL on Linux.

Caveat: both the Microsoft and the Mono C# compilers loads libraries from their "base directory", never from the Global Assembly Cache.

In Mono, the csharp command happens to be in the same directory as the rest of Mono, so loading implicit libraries just works (Loading System.Core for example). But when running our csharp command on Windows, unless you put the binary in the same location as csc.exe the REPL wont be able to load libraries using their short names.

This is particularly obnoxious because to use LINQ you need to use the full assembly name, or copy csharp.exe to the directory that contains System.Core so you can just do:

	csharp> using System.Linq;
	csharp> from x in "Foo" select x;
	

Future work

Public API: There is still some work left to do: we need to turn 99% of the public API in that assembly into a private API, the only class you should care about is the Mono.CSharp.Evaluator class, the rest you should consider internal.

The Evaluator API needs to evolve, right now it is a big singleton that exposes all of the variables defined as global variables. They really should be tied to some kind of context so we can support multiple and independent execution contexts on the same address space.

Chances are that we want to expose some of the internals of the compiler to the world, but we first need to figure out what makes sense.

Now that the code runs on .NET, hopefully those of you that wanted to embed it can provide us some feedback on how you would like to see this API change or even better, provide patches for it.

C# as a DLR language: Someone had suggested to also provide a hook into the DLR, so you can instantiate C# eval engines with the same API that you instantiate IronPython and IronRuby eval engines.

Silverlight support: in theory this works out of the box, but we have not tested it yet.

Contributions: Yes, we are accepting contributions to this awesome compiler.

Keybindings: Currently the csharp command line repl uses Emacs keybindings as part of my fabulous getline.cs command line editor. We are aware that developers of different faiths might find other keybindings more appropriate. We are taking patches.

Add support for IKVM Reflection: Jeroen has written a drop-in replacement for System.Reflection[.Emit] that will allow us to decouple the compile from the profile that it compiles code for (Monoistas are familiar with dmcs, smcs, gmcs and mcs; We will be able to have a single compiler).

Source Code and Hacking

The source code for Mono's C# compiler, the Compiler as a Service and the interactive REPL are all available from SVN, do a checkout from our subversion repository for the module "mcs".

Download from GitHub the "mono" module

Then open the VS2008 solution in mcs/tools/csharp. This will build the Mono.CSharp compiler as a service library and the csharp tool.

We do not typically provide VS Solution files for most of Mono, but we are making an exception for the compiler as a service to encourage .NET developers to play with it.

Update: Our compiler is MIT X11 licensed, so even developers at Microsoft can download this code and look at it. It is all kosher guys!

Today we released MonoMac, a new foundation for building Cocoa applications on OSX using Mono.

MonoMac is the result of years of experimentation in blending .NET with Objective-C and is inspired by the same design principles that we used for MonoTouch.

It is also the result of weekend hacking as our day to day work revolves around Mono's efforts on Linux servers, Linux desktops, Visual Studio integration and our mobile efforts. Luckily, it shares some components with MonoTouch.

To get MonoMac, you need to get two modules from GitHub: monomac and maccore.

Background

Many years ago Geoff Norton produced CocoaSharp, the first set of .NET bindings to the Cocoa API. CocoaSharp was a fine first binding at the time and it was a good place to start learning about the challenges of binding Objective-C APIs to be consumed by .NET clients.

Over the years three other frameworks were created to integrate the Objective-C world and the Objective-C APIs with C# and other .NET languages. Each one of these new frameworks had its pros and cons, and a year ago we made a call for all three competing frameworks to be merged, but sadly nothing came out of it.

When we created MonoTouch, we wanted a binding for the Cocoa APIs that would fit the patterns and idioms used in the C# and .NET worlds, that would comply with the .NET Framework Design Guidelines and would allow give developers all the tools required to build full Cocoa applications.

We had two main requirements: the binding should just work and the code should be MIT X11 licensed. For the binding to just work, we turned to the .NET Framework Design Guidelines book as it captures years of design decisions, programming idioms and advise that would help C# and .NET developers. By following the Design Guidelines we:

• Avoid surprises
• Blend with other C# and .NET libraries
• Reduce the room for errors
• Increase developer joy
• Minimizes time for the developer to be productive
• Every bit of existing .NET knowledge translates

Luckily for us, .NET was designed from the start to be an interoperability framework. A framework that supports the most advanced requirements to make multiple runtimes and frameworks to communicate seamlessly with each other. We used these features to create our bindings.

The above goals turned into the following technical requirements:

• Developers should be able to consume Cocoa APIs as C# APIs
• Allow developers to subclass Objective-C classes
  • Subclass should work with C# standard constructs
  • Derive from an existing class
  • Call base constructor
  • Overriding methods should be done with C#'s override system
  • Do not expose developers to Objective-C selectors
• Provide a mechanism to call arbitrary Objective-C libraries
• Make common Objective-C tasks easy, and hard Objective-C tasks possible
• Expose Objective-C properties as C# properties
• Expose a strongly typed API, for example instead of exposing the generic-container NSArray or individual NSObjects. This means that developers get a few benefits:
  • MonoDevelop can flag errors as you write the code
  • MonoDevelop can present documentation popups on types, methods, properties and parameters as you type them.
  • Minimize runtime errors by catching invalid casts at compile time.
  • Encourage in-IDE API exploration without rebuilding, and without having to look up the types in the documentation.
• Turn int and uint parameters that should have been enums as C# enumerations and C# enumerations with [Flags] attributes
• Expose the basic Foundation as C# native types:
  • NSString becomes string
  • NSArray becomes strongly-typed array
• Events and notifications, give users a choice between:
  • Support the Objective-C delegate pattern:
    • Strongly typed version is the default
    • Weakly typed version for advance use cases
  • C# event system
• Class libraries should be MIT X11 licensed, like the rest of Mono's class libraries.
• Expose C# delegates (lambdas, anonymous methods and System.Delegate) to Objective-C APIs as "blocks".
• Curated APIs: there is no point in binding every UNIX or CoreFoundation C API available, as those are not very useful in practice. Bind only those that are required to build applications or get access to mandatory functionality.

More information about our API can be found here: http://monotouch.net/Documentation/API_Design

Binding Cocoa

Cocoa consists of two sets of APIs, one set is an object oriented C-callable API and another one is the Objective-C based API.

C-based APIs were bound using a traditional P/Invoke approach where the C-based API is wrapped in a C# class. This includes APIs like AudioToolbx, CoreGraphics, CoreFoundation and CoreText. There is very little magic in these bindings, they are straight forward bindings, similar in spirit to what you would do if you wrapped those APIs for C++ use. I am in particular very proud of the much simpler AudioToolbox API.

The Objective-C APIs is where the UI heavy lifting takes place and where most of the high-level functionality is found, and this includes APIs like Foundation and AppKit. The Objective-C APIs are bound using a new binding engine (MonoMac.ObjCRuntime) and the btouch binding generator.

The btouch binding generator consumes an API contract in the form of a C# source file and generates a binding that matches the specified contract., for example, this is the API definition for the NSActionCell:

	[BaseType (typeof (NSCell))]
	interface NSActionCell {
		[Export ("initTextCell:")]
		IntPtr Constructor (string aString);
	
		[Export ("initImageCell:")]
		IntPtr Constructor (NSImage  image);
	
		[Export ("target")]
		NSObject Target  { get; set; }
	
		[Export ("action")]
		Selector Action  { get; set; }
	
		[Export ("tag")]
		int Tag  { get; set; }
	
	}
	

We produced a comprehensive guide to binding Objective-C APIs with MonoTouch that applies directly to MonoMac.

Since a lot of the work of binding an Objective-C API is very repetitive, we have also included a header parser that does most of the heavy lifting in producing the above API from the Objective-C header file. The parser output then needs to be then massaged a bit to produce a binding that satisfies our design requirements. For example, NSArray arguments and return types must be looked up on the documentation and the proper strong typed inserted.

Status

Unlike MonoTouch, MonoMac is not a complete binding for all of the Cocoa APIs at this point. This has been a weekend effort for Geoff and myself but it has reached the point where it can be used for building applications and it has reached the point where we can start taking contributions to the effort.

Currently MonoMac binds:

• CoreFoundation (the parts that are needed, see the design principles)
• CoreText (done)
• CoreGraphics (done)
• Foundation (the parts that are needed, and helper tools to support the rest)
• AppKit (About 30% left to be done)

If you are interested in advancing the state of MonoMac, we are currently looking for contributors to help us bind the other Objective-C frameworks and help us complete AppKit.

Where we are going

MonoMac is merely the library that gives C# developers access to the underlying APIs on OSX, it does not include the tooling necessary to create a full application bundle.

Luckily, MonoDevelop has already most of the code needed in the form of the MonoTouch plugin. We will update this plugin to also support creating full application bundles for OSX.

A new feature that developers will be interested in is the new "Mono bundler" tool that we are hoping we can include in Mono 2.8. This bundler examines your .NET application and generates an application bundle that contains both your application code and any dependencies that it needs from Mono in a self-contained package.

This is the technology being used by Banshee on OSX today. The tool constructs a self-contained application based on your system installed Mono that you can distribute to your users, without requirement them to install Mono in the first place.

But we need your help. There are many small and medium tasks that developers can help us with that will free our already busy weekends and will allow us to have a full MonoMac experience done in a shorter period of time.

The more help we get, the sooner this will be done.

We need contributors in the following areas:

• API binding for the rest of the Frameworks
• We need samples to be written
• We need tutorials to be written (like the ones we did for MonoTouch)
• We need to port existing Cocoa samples to C#:
  • To exercise the binding
  • To serve as reference for new developers
  • To identify missing frameworks
  • To prioritize bindings
• We need to alter MonoDevelop's plugin to produce OSX Application bundles.

Please join us on the mono-osx mailing list to discuss the future of MonoMac.

Update Currently this requires a preview Mono to work from http://mono.ximian.com/monobuild/preview/download-preview/

We have just released MonoTouch 3.0.0 with support for iPhoneOS 4.0's new APIs. To try it out, you need to have Apple's iPhone 4.0 SDK installed otherwise MonoTouch 2.0 wont let you download the new toolkit (since it is Apple confidential at this point).

This release is a preview, the final release will be some sort of 3.0.XX number.

This release includes API support for the features that Apple announced last week, in broad terms:

• Background application support
• iAd support
• Local notifications
• Game Center support
• Support for enterprise data protection

We also sneaked in some new work that is not bound to the iPhoneOS 4.0 API and can be used when building for iPhoneOS 3.1.x and 3.2.x:

• Size reductions:
  • Linker updates to reduce executable size
  • More fat trimmed from the final executable.
  • "Hello world" is 500k slimmer now
• Native support for Objective-C blocks on the binding generator:
  • Exposed as C# delegates
  • Both lambdas and anonymous methods can be used as blocks
  • Standard C# semantics for variable capturing

We have released a big update to Moonlight on Linux, our Moonlight 3, Preview 6.

New in this release:

• Chrome support and chrome packages
• Many performance improvements
• Most Silverlight 3 features are in now, including taking apps out-of-browser
• Hundreds of bug fixes and improvements our Silverlight 3 compatibility story

Remember to file bug reports. If you do not file a bug report, we have no way of knowing that something is not working.

The ECMA working group that drives the Common Language Infrastructure standard (ECMA 335) has published the working draft for the 2010 edition of the standard.

These are the work-in-progress documents that the team is working on.

In addition to the Novell mirror copy above, you can get the standard from the following sites:

• Eiffel Software (http://www.dotnetexperts.com/ecma/)
• Microsoft Corporation (http://msdn.microsoft.com/en-us/netframework/aa569283.aspx)
• Novell Corporation (http://mono-project.com/ECMA-335-CLI-Public-Draft)
• Kahu Research (http://kahu.zoot.net.nz/ecma/index.html)
• Twin Roots (http://twinroots.com/ecma/index.html).

This year, Michael Hutchinson is the administrator for Mono's involvement in the Google Summer of Code.

We are looking for motivated students that would like to either work on one of the ideas that we listed in our Student Projects page like work on MonoDevelop's IDE, Mono's runtime, Mono's class libraries and in Mono-based applications.

Additionally, if you are a student and you have been thinking "The Mono guys really should do...", do not hesitate and propose your idea. Perhaps you get to implement your idea, get paid to do so, and be mentored by our group of awesome C and C# hackers.

If you are a student, you can apply here and Google has a convenient list of frequently asked questions about the program.

Remember: There are only 3 days left.

We just released our updated version of MonoTools for Visual Studio:

A tool that helps Windows/.NET developers target Linux systems directly from Visual Studio, this release is still intended to be used with Visual Studio 2008 and includes some important improvements:

• Smarter Remote File Copying
• Automatically Detect Future Updates
• Preview of Visual Studio 2010 Support
• Easier Packaging of Precompiled Web Applications

We are hard at work on our 2.0 release that will include soft-debugging support, MacOS support and will also run with Visual Studio 2010.

From Steve Jobs 1997 presentation when he announced his partnership with Microsoft:

Where we are right now is, we are shepherding some of the greatest assets in the computer industry.

If we want to move forward, seeing Apple helping an prospering again.

We have to let go of this notion that for Apple to win, Microsoft has to lose. We have to embrace the notion that for Apple to win, Apple has to do a really good job. And if others are going to help us, that's great. Because we need all the help we can get. And if we screw up and do not do a good job, it is not somebody else's fault, it is our fault.

So I think that is a very important discussion.

If we want Microsoft office on the Mac, we better treat the company that puts it out with a little bit of gratitude. We like their software.

So the era of setting this up as a competition between Apple and Microsoft is over as far as I am concerned. This is about getting Apple healthy and this is about Apple being able to make incredibly great contributions to the industry and get healthy and prosper again.

I feel exactly this way about open source. For open source to win, we do not need Microsoft, Apple or proprietary software to lose. The industry is not a zero-sum game, not only we enrich each other's platforms by exploring different ideas, but it is also incredibly healthy for the industry to have a blend of different approaches to computing.

Open source software leads in some areas in the industry and we as a community are very proud of its success. But when it comes to the areas where open source has not delivered a full solution like our proprietary competitors have, we resort to finger pointing and blaming others.

Some in the open source movement would like all the software in the industry to be open source/free software. Desktops, servers, games, embedded systems and everything that every human touches.

Although it is a noble goal, it has set people up for suffering by making the goal unachievable. It has been 15 years since the rise of the first large open source companies and by now we should know that our dream of a pure open source stack ruling the world is not going to happen any decade now.

Luckily, today, we have a much better understanding of where open source works and where it does not.

It would do us good to ponder Steve's 1997 message:

And if others are going to help us, that's great. Because we need all the help we can get. And if we screw up and do not do a good job, it is not somebody else's fault, it is our fault.

Once again, I want to recommend Ben Zander's The Art of Possibility book, a book with various recipes on how to look at the world through new eyes.

It seems that David's article on Windows strategy tax on .NET lacked enough context for my actual quotes in there.

When David contacted me, he was writing a piece on the evolution of .NET and since he was speaking to Microsoft, he wanted to get feedback from other people on what we thought Microsoft got right and what they got wrong. This is how my email to David started:

Well, I am a bit of a fan of large portions of .NET, so I might not be entirely objective. You might want to also get some feedback from a sworn enemy of Microsoft, but you should get at least the statements from a sworn enemy that has tried .NET, as opposed to most people that have strong opinions but have never used it.

David said:
Given your familiarity with the framework, are there any iterative changes that you find questionable or you feel require some explanation?

There are certain areas that I do not quite like about .NET, they are not major issues as they can be either worked around or ignored (to some extent), but here are some.

And this is where the quote on Microsoft shooting the .NET ecosystem comes from, I reproduce from my email for the sake of completeness, none of this is a secret:

The most important part is that Microsoft has shot the .NET ecosystem in the foot because of the constant thread of patent infringement that they have cast on the ecosystem. Unlike the Java world that is blossoming with dozens of vibrant Java virtual machine implementations, the .NET world has suffered by this meme spread by Ballmer that they would come after people that do not license patents from them.

Sun on the other hand said from day one: we will not sue you over patent infringement if you implement your own Java. Google does something similar with their APIs and Google's Wave: they are giving everyone access to their stuff.

As the only implementor of the ECMA standards outside of Microsoft, I sure would have hoped that they had given rights to everyone to implement. They would still be the #1 stack, but it would have encouraged an ecosystem that would have innovated extensively around their platform.

Instead, people went and innovated on Java or other platforms that might not have been as advanced as .NET, but at least they were not under Microsoft threat.

Google could have used .NET, Rails could have been built on .NET, the Wikipedia and Facebook could have been built using ASP.NET.

All of those are failed opportunities. Even if the cross-language story was great, the web integration fantastic, the architecture was the right one to fit whatever flavor of a platform you wanted, people flocked elsewhere.

This is their largest mistake, and it is perhaps too late to do anything about it.

It took Microsoft eight years, a new management and a fresh set of eyes to change some of these mistakes. The veil of threats that existed over the runtime in 2001 was lifted with the Community Promise announcement but it took eight years, and those were eight years of lost opportunity and FUD directed at all things Microsoft.

I still believe that Microsoft lost a great opportunity of having .NET become the universal runtime of the net, and they could still have the best implementation. I still believe that they should put the rest of .NET under the Community Promise or OSP and even with Mono as an open source implementation, they would retain their edge.

On Innovation on other Runtimes

David quotes Ted Neward (a speaker on the .NET and Java circuits, but not an open source guy by any stretch of the imagination). Ted tried to refute my point about Java and innovation but seemed to have missed the point.

The article attributed this to Ted: "Microsoft has made an open-source CLI implementation codenamed 'Rotor' freely available, but it has had little or no uptake".

There is a very simple reason for that. Rotor was not open source and it was doomed to failure the moment it came out. When Microsoft released Rotor in 2002 or 2003 they had no idea what they were doing and basically botched the whole effort by using a proprietary license for Rotor.

Rotor's license was "look but do not touch" and prohibited commercial use of it. This is a non-starter for anyone that wants to call their software open source. Had Rotor been open source, we would have just used that instead of building Mono and we would have invested in it.

The article also gets the facts on the interest on Java virtual machines wrong. Certainly only a handful are used for large server deployments, but minor Java VMs were part of the Java culture for years. Fine-tuned versions of the JavaVM are used for all sorts of embedded scenarios and it has also been used extensively in research.

The Jikes RVM Java implementation is still an important playground for researchers where new garbage collectors, code generator technology, large memory problems, and optimization have been prototyped and tested. The open source Kaffe was the first open source JIT engine and it lead to way for many developers to explore the problems of cross platform JIT compilation, Japhar lead the way for a full open source class library stack (this became GNU class path). The Cacao open source VM explored new code generation optimizations techniques that were eventually used by other JIT engines.

In the industrial world, variations on Java were used for embedded systems, the most popular one today is Dalvik, Google's runtime for a Java-like runtime.

The list above is by no means comprehensive and the above is merely the innovation that happened in the JavaVM world. What is clear is that .NET/ECMA CLI fixed a lot of the design mistakes in Java, improved in many areas and built on the knowledge that had been gained from Java.

But my point about the ecosystem goes beyond the JVM, it is about the Java ecosystem in general vs the .NET ecosystem. Java was able to capitalize on having implementations on Linux and Unix, which accounts for more than half the web today. The Apache Foundation is a big hub for Java-based development and it grew organically.

Had Microsoft been an open company in 2001 and had embraced diversity we would live in a different world. The awesome Mono team would probably be bigger, and the existing team members would have longer vacations.

But for everyone that missed the point, luckily, Microsoft has new management, new employees that know open source, fresh new ideas, is becoming more open and is working actively on interoperability with third parties. They even launched the CodePlex Foundation.

As I told David on that interview, I am still a fan of .NET, and we are going to continue working to bring Mono everywhere where we think we could improve developer's experience. We are actively working on improving Mono on Linux, Mono for MeeGo, Mono for OSX, Mono for the PlayStation, Mono for Xbox360, Mono for the Wii, Mono for the iPhone, Mono for Android and Mono everywhere.

Just like everyone that complains about Sun's tight control over the Java development process, I have my own regarding Microsoft's development process for .NET. But that is just business as usual.

The best C# and .NET days are ahead of us.

Microsoft is trying to succeed where web services failed before with their new Open Data Protocol (oData).

A few years ago, I had an epiphany when listening to Don Box talk about data services and web services. Web services and web sites are merely public facades to your internal databases. Web sites expose your database rendered as HTML while web services expose them in some sort of data format, defined on a case-by-case basis.

With Web Services, developers need to define what bits of information should be exposed and how it is exposed (this applies to both SOAP and REST-based services). The problem is that developers might not have the time to spend on exposing every possible bit of interesting information that you maintain in your databases. Most importantly, there are very few web services that provide server-side queries making the information harder to mine.

oData is a little bit different, for a given oData endpoint (like http://odata.netflix.com/Catalog/CatalogTitles) you can request that the server do some work for you, for example, you can pass a query that will limit the results to only those that you are interested in, and you can also specify the information that you are interested in.

For example:

• Movies released this year ($filter=ReleaseYear eq 2010).
• Movies released this year, that have bank in the synopsis ($filter=substringof('bank',Synopsis) and ReleaseYear eq 2010).

It seems like Microsoft is doing the right things to get oData to be adopted. It reused Atom as the exchange format, made the services REST-based, it made client libraries available for many developer platforms and placed the spec under the OSP.

Consuming oData sources

Microsoft is taking a very Google-y approach with oData. They have created client libraries for a wide range of platforms to encourage adoption of this new way of exposing data.

In addition to the JavaScript, Java, PHP, .NET and Objective-C bindings, Microsoft has announced that they will be open sourcing the .NET client library under the Apache 2 license. I was pleasantly surprised to learn that they were open sourcing this code, as we can consume it right away on Mono.n

So this is good news for everyone that wants to consume the information. The bindings for .NET are in particular great since you get strongly typed client-side code that you can use to invoke remote servers.

Producing oData: the need to open source System.Data.Services

This is trickier, and I believe that if Microsoft wants to bootstrap the oData universe they need to seed this space not only with some existing services but also with an open source OData server implementation for Unix.

I should further add that they should not wait a single minute and open their server-side .NET implementation if they want to accelerate the oData adoption.

Let me explain why.

Although the client libraries are great step to drive the adoption of the protocol for clients, it will do very little to unlock the data that sits today out in the web behind Linux servers running PHP, Java, Ruby or Python-based applications.

At the end of the day, the client side code is a relatively simple parser for an XML file format. The server side on the other hand is much more complicated to get right.

The server side requires a complete implementation of the query syntax, selection as well as access control and transaction support required to expose the data safely.

It is clearly possible to implement the oData server technology, IBM did it for WebSphere, but this is an unnecessary wait. Placing a standard under the OSP and documenting it is not enough to drive open source or even third party implementations.

If Microsoft were to open source their server side implementation of oData, we could overnight allow Linux users to expose their data in a format that can be mined. Linux users would only need to run a Mono front-end to the System.Data.Services library to expose the data that currently lives in their servers and is being served by Joomla, Wordpress, Rails, Django front-ends to become available as data services.

Witness what happened with the M modeling language: great idea, OSP-covered, and yet the steep work required to implement it means that not a single implementation has been created in the 18 months since the project went public.

Update: I stand corrected, Douglas Purdy points out that there is an open source implementation of M built with Javascript here.

Ok, so not the best example, risking another egg in my face, I want to say that chances are that jsmeta is not a complete implementation of M.

More on oData

A detailed overview is available on the oData site.

The best intro to oData that I have seen is Douglas Pourdy tour-de-force during the second day keynote as he walks through all the pieces in a span of 20 minutes.

The MIX sessions on oData are packed with great information. The transaction and access control requirements on the server-side support are discussed on the How to create a feed for that session.

If you want to explore oData services, you can use this Silverlight application to build your queries.