Next steps and why some cool things are just cool at first sight, sigh!

I guess my next little toy project will be around aggregation. Not that I won't continue adding stuff to "dasBlog", but I am quite happy with the status as of now and once we've got Stephen's caching work in the project, we'll make it a 1.2 .

So, the other bigger chunk of code that I have sitting around here from the blogging infrastructure that I wrote but didn't get done in the first quarter of this year (and from which the rendering engine made it into dasBlog) is a pretty serious, extensible syndication engine based on Enterprise Services and SQL Server. Pulling in RSS feeds is, in my view, a background server task. A common infrastructure for subscribing, queuing, requesting, transforming, filtering, caching and pushing out results (via LCE) is something that could be very handy, makes a great demo and there's lots of sample data to gather in a short time ;)

I am not at all interested in writing yet another aggregation GUI. I may grab one of the available aggregators like SharpReader or RSS Bandit and hook it up for demo purposes, but that's about it.

So ... while looking around for tools I could use, I found this cool extended stored procedure for using .NET Framework regular expressions straight from within SQL Server. Hold! What I also found (and I actually looked for it) was this Microsoft KB article (Q322884) that states that extended stored procs written in managed code "is not supported". 

Based on some discussions I had with members of the SQL team about the next release of SQL Server (Yukon) earlier this year about their work around incorporating the CLR (the fact that they're doing that is public so I am not violating any of the papers I signed), this absolutely doesn't come as a surprise to me and the bottom line is: This stored procedure looks cool, but shouldn't get near a SQL Server 2000 production server, ever.

The reason for that is that SQL Server is essentially an operating system by itself. It does its own memory management, can do its own thread scheduling (it makes use of  fibers, which are self-scheduled threads) and has, of course, its own I/O system sitting on low-level OS functions. The CLR doesn't know about any of that and SQL Server 2000 doesn't know about the CLR. If you are writing a stored procedure in unmanaged C/C++, you create just a DLL that runs on top of Win32 and if you follow a couple of rules, you should be ok. If you are writing in C# or VB.NET, you are bringing along an environment that doesn't know anything about these rules around SQL's use of threading and thread local storage, probably wants to launch additional threads under the covers and whose garbage collector hasn't been designed to cooperate with SQL's memory management. Yes, it may run, but what happens under stress or low memory conditions? How does it affect transactions? What's the story around performance once the CLR is present in the process and is probably used in only one of 500 queries?  I know that putting the CLR into Yukon is nothing that a someone at Microsoft does in a day or two and therefore I doubt that putting the CLR into SQL 2000 within half a day is a good idea for a real system. Things are different if you are running inside what essentially is an OS kernel.