October 2008 Archives

As I wrote in my earlier post, I am working on System.Web.Routing which is new in .NET 3.5 SP1. The code is almost done, and I want to bring it into Mono 2.2 (as opposed to current planned version: 2.4), that is to be branched soon (next month). But I need some dogfooding to mark it as stable. If any of you have or know free sample resources that use this API, let me know.

As part of dogfooding, I am sort of working on System.Web.DynamicData API (some of you might have noticed that I also checked in some implementation), and looks like its use of Sys.Web.Routing is working (since it is okay for me if routing part is working so far, I haven't dug in depth). I'm not sure if I continue DynamicData hacking though (as it is leaving routing part anymore).

And yes, Linq to SQL / dblinq effort continues.

Here I write about some of my recent commits. It does not mean I wrote all of those code. I often commit others' work.

Michael Barker posted a set of patches to implement System.Messaging.dll based on RabbitMQ client C# binding. He once posted a patch for the same purpose but based on different concept. So, it is not a short story, at least for him ;-)

Since MSMQ and JMS/AMQP-based servers have different concept in their designs, the implementation will not cover large part of the functionality that System.Messaging API, but it may be of help for some System.Messaging users.

Since we are not sure if we go with this implementation strategy, it is currently checked in to its own branch. What I personally want to see is some different implementations of its Mono.Messaging SPI, for example, based on Win32 API (I don't love it but probably it is the easiest to test the SPI). We welcome contribution here :)

Originally I was looking for practical use of ASP.NET Routing functionality in .NET 3.5 SP1, and ended up to think that Dynamic Data uses it. For routing part, it looks almost simple, so I sort of decided to hack it.

During generating masterinfos, I quickly noticed that DynamicData depends on LinqDataSource control, which we don't have yet. Fortunately, LinqDataSource seemed a good candidate for dogfooding Linq to SQL effort that we are trying to implement with DBLinq project (as written in my previous post). So I started to hack it.

And now here is a screenshot of working example of our LinqDataSource :)

It is from very simple use of GridView and LinqDataSource, which depends on SQL Server database that Pablo's sample creates (see my previous post for the details).
LinqDataSource-test.zip

It's working here, but it is possible only with my private branch of System.Data.Linq. Also I had to hack DataContext .ctor(string, MappingSource) which is not implemented in DBLinq (there is a discussion on how to implement connectionString support - see this thread in the DBLinq mailing list archive). The change is: : http://monoport.com/37676

This time it is a sshot from Windows as I am running this sample to connect to local SQL Server, but it is not difficult to get it working with other DB engines. For example, SQLite version of the sample would work if you 1) remove "dbo." from every table attribute in the sample code DataClasses1.designer.cs, 2) change connection string for SQLite DB, and 3) change my hack to instantiate SqliteConnection (must be done through reflection; we don't reference Mono.Data.Sqlite types from System.Data.Linq).

Anyways. The whole effort (DBLinq, DBLinq integration and LinqDataSource) is in early stage. We need more code. Especially LinqDataSource is nothing but hack yet ;)

One of the recent project I am sort of involved is an ongoing effort to implement System.Data.Linq.dll, a.k.a Linq to SQL, with DBLinq project. DBLinq is designed to be like Linq to SQL, but opens the door to support more database systems than SQL Server.

The Bootstrap

When I was asked to get involved in Linq to SQL work in this spring, I drew a rough sketch to implement S.D.Linq.dll based on DBLinq. In the middle of May, Jiri Moudry, one of the core DBLinq hacker, was also starting to work on Mono support. Occasionally we were in the middle of Google Summer of Code (SoC) program (beginning phase) and there was a student who was interested in Linq to DB. The student, Pablo Iñigo Blasco, became the core hacker of this effort. In fact, at first I was rather cautious about it: I haven't drawn good-enough picture of how to get every party involved yet, and especially I definitely needed to talk with DBLinq hackers.

Actually, at first I wrote System.Data.Linq API implementation as a wrapper on top of DBLinq. At that time, DBLinq was designed to be dependent on System.Data.Linq.dll. I thought that I had to resolve this issue (as it is a circular dependency), but it turned out that Pascal Craponne, another core DBLinq hacker, explained their plan to implement System.Data.Linq API by themselves(!) I quickly discarded my implementation and started rethinking about the SoC project with Pablo, which now became much hopeful than before. After all, it started off so well.

DBLinq changes for "Mono_STRICT" mode

When the SoC project started in June, the DBLinq team was busy on "sugar" expression tree implementation. So, I asked Pablo to start from writing samples for DBLinq which could be later ported to use S.D.Linq API. He did awesome job.

In the middle of June, as Pascal finished the first sugar work, we started to talk about Mono integration. Including the purpose to clean up the code, they introduced #if MONO_STRICT code.

Our need for the API was however somehow messy: we had to eliminate extra API members from the resulting System.Data.Linq.dll. And DBLinq itself is extensible enough to allow developing third party "vendor" API and hence exposing a lot of extra members. I had messy concern; I was afraid of getting final System.Data.Linq.dll cutting extra database support than SQL Server, since SQL Server is the only public vendor in System.Data.Linq API. (The concern didn't go away until recent talk.)

After a lot of discussion, Pablo came up with his nice Roadmap to build both DBLinq full and Mono's System.Data.Linq from the same code base, and he quickly made it.

Pablo continued and continues contributing to DBLinq project. I'm extraordinary glad to see his achievement and continuous participation to the project. I thank to all those guys who made it happen :)

Trying it out

Currently we still haven't integrated DBLinq source into our mcs tree yet. Though, I often create System.Data.Linq.dll based on their effort. For now, I have an archive: System.Data.Linq-20080930.zip - replace existing mcs/class/System.Data.Linq with the expanded directory, renamed as System.Data.Linq. And then run make (you need make clean).

As the end of the Soc project, we needed a working sample code for review. So I asked Pablo to cook some instruction, and he wrote it. With the latest svn version the test somehow hit NotImplementedException in "sugar" now, but it'd show you current DBLinq / System.Data.Linq implementation status.

A problem is that the current System.Data.Linq.dll contains only support for SQL Server, so you have to use it for now.

Help DBLinq effort

Yes, there is not a few things that need to be implemented. DBLinq project guys are calling for contributions. If you are interested in joining the effort, that'd be awesome. It helps Mono too.

Other than DBLinq (and System.Data.Linq) itself, there are also some interesting stuff to help this effort: ASP.NET LinqDataSource control in .NET 3.5 SP1 uses Linq to SQL, so implementing it will help dogfooding System.Data.Linq API. DynamicData may also help dogfooding, but that needs some extra love (it looks dependent on LinqDataSource). There's a lot of fun stuff here.