Back to blogland. Looking back at this year, i have hardly blogged at all. Partly because I wad too busy and partly because I just had better things to do with my free time. Anyways, in the upcoming weeks I'll write about the things that I've been quietly building in the past half year or so and also dig into and publish stuff from my code archive where I still have some gems laying around that should really be published before they get totally useless. I even have a very cool NETFX 2.0 update for this here.

Part of what I am going to blog about and explain in quite some detail is the (code-named) "Clemens TV" project, which I keep working on. As things stand right now, there are so many variables and configuration issues with getting this to work for everyone (or "anyone but myself" for starters) that it doesn't seem feasible from a support perspective to make all of it public in the same way as I did with dasBlog. Instead, I'll publish a framework that allows hooking in all sorts of (self-written) live TV providers into a common (Indigo/WCF) server app. I will publish a provider for public web streams.

However, if you happen to use SnapStream's Beyond TV and have an additional Beyond TV Link license (that's required for the Beyond TV provider for the app), you have at least one software encoding TV card (hardware encoding cards won't work for web streams), and you have a connection with at least 256 KBps upstream, drop me a line to clemensv@newtelligence.com and I'll put you on a short list for those folks who might get the provider for testing (and to keep) once I am happy with it. We'll see where we go from there.

That said, the application is only partially about TV. It's a showcase demonstrating that Indigo is not only about pushing SOAP envelopes around. I am sending RSS, ASX, OPML and multi-gigabyte, restartable MPEG downloads through Indigo channels and all the receiving application sees is a plain old data stream or plain old XML (nicknamed POX). And when I want to record a show I send an HTTP POST to an endpoint to update the episode details and add a recording and when I want to cancel the recording I send an HTTP DELETE to remove the recording job. That smells like REST. I am sure Mark Baker will dig Indigo once he sees my set of ServiceModel extensions

Anyways, this is just a "heads up" that it's probably worth looking this direction in the upcoming weeks, no matter whether you are checking out Indigo today or are doing stuff with shipping technologies such as Enterprise Services.