It's just not threaded properly. It can't be.

I noticed long ago that it uses worker threads to update feeds, and often when a feed fails to update, that worker thread (most likely a pool thread) becomes a zombie. Over time, this further degrades performance until the pool just runs out of available threads (not to mention the memory consumption is just insane by then). The only remedy is to shut down the program completely and restart it... giving you a day or two before having to kill it again.

And now this - I have noticed what can only be described as "anomalies" in my downloaded feeds before... things like seeing comments attached to the wrong posts, and so on. I always assumed this was just due to bugs in the RSS feed producer I was subscribed to. But today, on a pair of blogs, both had a post with a title of "{...}". Each had a jumble of intermixed text from recent posts in the other blog. In order to get the feeds sorted out properly, I had to delete them from my opml, restart RSS Bandit, and add them back. And of course, there are no posts on either blog titled "{...}".

I suppose the corrupted posts could be due to buggy local storage code, but it sure looks a whole lot like the updater threads are just poorly monitored and synchronized.

I guess it's time to try NewsGator. I am not thrilled about packing my RSS feeds into Outlook, but guess I will get used to it.

At least they have a free trial period though. I hate paying for something and tossing it out shortly after.

Three new specs were released as W3C recommendations today...XML-binary Optimized Packaging (XOP), SOAP Message Transmission Optimization Mechanism (MTOM), and Resource Representation SOAP Header Block (RRSHB).

They are all interrelated... XOP is the XML mechanism that is the building block for MTOM (SOAP implementation of XOP which does not dictate wire protocol binding), and RRSHB is an expansion of the SOAP HTTP binding to support MTOM/XOP.

In a nutshell, all of this stuff has one essential purpose: Freeing you from having to encode binary data into base64 when you serialize a SOAP message. Basically, base64 is a really heavyweight encoding scheme, that adds a TON of fat. By allowing binary octet data to actually be transmitted unencoded (and under certain circumstances, relayed across SOAP processors unencoded) instead of taking the serious encoding hit, the bandwith requirements of moving large messages around is reduced significantly. Not only that, but the CPU overhead of doing the base64 encoding/decoding is also alleviated. And yet another, though smaller, benefit is that less buffer resources are required on both ends of the pipe (assuming both ends can deal with the data in it's raw format). Of course, some operations may require access to the data in base64, so a SOAP sender or reciever may have to encode/decode it anyways (I think XML-Signature requires binary data to be addressable in base64?)... but it still gets the bandwidth reduction when it is transmitted over the wire.

I can see a lot of benefit to this.

For example, this makes digital media transmission over web services a whole lot more appealing (as opposed to scrapping together a proprietary protocol). SOAP-routed media could turn out to be quite interesting. I know folks have tried to do it with Web Services, and gave up in frustration due to the bandwidth hit... but now the hit isnt there... it's now basically raw media data wrapped in some dandy XML metadata... fascinating...

Another use I can see is just around the corner when ADO.NET 2.0 datasets support REAL binary serialization instead of the "serialize to pseudo-xml, and call it 'binary'" serialization of ADO.NET 1.x. In a purist sense, we know it's bad form (argue it here, here, and here) to send datasets over web services "Data on the Inside vs. Data on the Outside" and all that. But I tend to agree with the opinion that in most cases once we commit to sending a dataset in a message, it becomes "opaque" like an image or any other binary data would be... and doesn't really break the purist view (come on, squint real hard with me). So passing a large dataset in binary format is perfectly acceptable to me, and these new specs will make it significantly more viable. One of the major debate points against datasets over webservices has been the bloat it causes... but with binary serialization and XOP/MTOM, that arguement fades fast.

Of course like anything else, I am sure someone somewhere will find a way to abuse the specs and I will be griping about it later.

The word this week is that on Friday there should be a set of new application blocks released on the MSDN patterns and practices site. We can expect a new Data Access and Logging block, as well as a Cryptography block, and a few other treats. Sounds like a pretty good pack of reusable blocks, so I for one will be keeping my eye on MSDN tomorrow.

[update:] The new blocks are now online at this url: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/entlib.asp

This one is great...

http://wizbang.mirror.unitedemailsystems.com/vw_20_b3.mov

What a stupid and obscure bug in VS.NET 2003. Thankfully someone figured it out and posted the fix on their blog (which didn't take all that long to find in Google). Making a note of it here in case it happens again. Who would have ever thought a DLL from the Visual C++ directory tree in Visual Studio would get unregistered simply by running a VS add-in deployment package install/uninstall a few times... and then would keep C# project wizards from working??

At least the fix is very simple and quick:

regsvr32 "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\vcpackages\csproj.dll"

Yes, thats cSproj.dll in the VC7 folder.

Brendon and Matt, The Atlanta .NET Regular Guys are going to resume this monthly event. It was put on hold for the last two months mainly due to holidays. It's a pretty laid-back meeting, often with very few attendees. In fact, it would be a record if some more folks swung by and raised our attendance to, say, 5.

In any case, tonight is the meeting for January. At 6:30 PM, you can find us at the 5 Seasons Brewery (Roswell Rd, just inside 285, in the back of the "Prado" complex). I am told they actually have a free WiFi access point there, so if you get bored with the discussion then you can always just surf some p0rn.

Swing by and join us!