Christian Nordbakk switched.

I am not done packing the code yet. (That's really a lie, because I have the installers sitting here, but I am considering some last-minute changes for some file names and don't want to create too much confusion once the stuff is out).

However, I have already put a good deal of the user documentation on the "dogfood" site where dasBlog is used to document dasBlog. I plan to put the downloadable files (one MSI for setting up a web and one to set up a code tree) over there by Wednesday and then I also will start filling in the "Code" section with some guidance on where to find what. The feature I love most is "Mail To Weblog".

This week:

• Ingo Rammer will be 24 on Thursday, if I remember right
• I am going to release DasBlog and throw a lot of source code at everyone ;)
• newtelligence will be 3 years old on Friday
• I will be 34 on Friday
• ... and there's one more thing we're waiting to happen on or before Friday

There's an option in Word to reduce the amount of odd markup Word injects into e-mail when used from Outlook ...

Dave Winer suggests an experiment:

Shall we run an experiment is to see if aggregators can work with RSS feeds that have a xmlns attribute at the top level, on the <rss> element?

... and continues with an example:

<rss version="2.0" xmlns="http://blogs.law.harvard.edu/tech/rss">

Now, the RSS spec doesn't say that this is okay, but neither does it say it's not okay.

Yes, the RSS spec may not but that doesn't matter, because it's just a vocabulary on top of existing specs that take matters a bit more seriously. The XML namespaces spec says: "If the URI reference in a default namespace declaration is empty, then unprefixed elements in the scope of the declaration are not considered to be in any namespace", which is true for all RSS elements as per RSS specification, because it ignores namespaces and is therefore subject to this default case. Therefore, setting a default document namespace like that may be permissible as per RSS spec, but recognizing such a document as valid RSS is just wrong. I would suggest to revise the spec and not to experiment.

Our buddy René Pierre Coburger understood the obvious name reference and made this little logo for the blog engine.

This was a fun week, really. Last week I was mostly at home and spent quite a bit of time (on the balcony, in the sun) refactoring BlogX and adding new features "offline". This week I tested and stabilized things using the online version, upgrading to a new build at least twice a day here at the office. I am quite happy with it. It's really cool playing with the stuff now. I think I am going to set up an additional, different blog just to play around with the features. But until now I needed your referrals and pingbacks and so on.

During this week I also thought about the naming issue, because -- as I pointed out before -- there's not much left of the original BlogX code base now and to limit confusion the thing had to get a different name (ChrisAn still gets proper credit in every single source file, of course). I had about two dozen ideas and it turned out that all of them were already taken either by some software or someone's personal blog and I also didn't want to hijack any of these names. So, I went for a very simple (sort-of) German variant: "Das Blog". So, it's "newtelligence DasBlog 1.0" now.

Some time this weekend, my buddy Stephen Forte is going to get a copy (he's the guinea-pig) and if he's happy with it, I'll check the stuff into a new GotDotNet workspace and then additionally post a web installer (that sets up a basic site) and an installer for the source tree by next week.

The feature-delta to BlogX as of now: Rendering using original templates from Radio, Pingback client/server, Trackback client/server, File-uploads, Picture uploads, web-based DTHML editor, Mail-To-Weblog with attachment and embedded pictures support, pick-up of referrals from redirects (from old blogs), mail notifications for pingbacks, trackbacks, and referrals on the permalink, refactored and streamlined access to the backend, safer file handling, subtitles, experimental Atom syndication support, per-item comment RSS files and "some other changes". I think I need force myself to work on documentation now and stop adding features.

Testing, testing ... MailToWeblog thread

Three minutes ago I was thinking "Theoretically, this entry should show up on my blog, in the 'Blog' category, in three minutes" and if you can see this, it did actually work.

I just deployed the first iteration of the last bigger chunk of work that I planned to do on the blogging software (for which we found a new name, meanwhile and you can find it at the bottom of the page). I can now send mail to a POP3-account, which the blogging engine watches. It will not only pick up the text, but will also extract and store any embedded pictures and attachments and link them to the entry. If this here works properly on the actual site, the only little thing I still need to do is to clean up the content for "text/html" so that only the stuff between the <body> tags is emitted into the entry.

This is a little document icon, which I added "as picture" in Outlook:

And here's the footer if it's attached as file:

Download: document.gif

Ingo says that "sealed" classes are a good thing and goes great lengths to explain why he thinks so in this article.

Now, I do have a little problem with his conclusion (which I still partially share, because I do write sealed classes every once in a while, but for a slightly different reason, see below) because the example he's using isn't really fitting the problem and he actually makes some assumptions about the ImageList class that aren't accurate in this context. 

First off, the property ImageList.Images isn't virtual and therefore cannot be overridden, at all. So that by itself is no reason to make the class sealed. The property has been introduced by the class, the class designer chose not to make it virtual. Can't be overriden, done. The same is true for all other properties except Container and Site, which are inherited from System.ComponentModel.Component. I fail to see anything on the ImageList class (not even a method) that really justifies the lockup using sealed considering the current version of the Framework. The bad that sealed does here is that I can't create a wrapper around the ImageList that simplifies setting up such a list in my specific environment.

Using sealed on a class is a very brutal thing to do. A more gentle way of using the sealed keyword is to say [void sealed override myMethod() { }], which essentially says: "Within my own class space I am using inheritance for this method, but since outsiders don't know what I am doing I won't let them override the behavior from here downwards in the class hierarchy." That doesn't affect the inheritability of the entire class and hence doesn't adversely affect the ability to wrap the existing functionality. 

Now ... is sealed on a class just plain evil? There are two answers:

• Yes. The keyword sealed on a class usually doesn't have much or any of a technical justification in the "here and now" version of a class library.
• No. The keyword sealed conveys a very clear message that the class designer reserves the right to change the class so dramatically in a future release of the product that you would be tremendously unhappy if you had derived from it to implement your own functionality, once that new version comes along. Sealed says: This is going to change in a big way.

 

The UDDI OPML list is now being cached in memory and refreshed every three minutes on a background thread. Unless the AppDomain recycles, the responses should be instantaneous now, unless you are doing a query on categories, because that needs to happen live because I don't want to cache each and every request combination on our server here and have it take up too much memory for this demo.

I looked at IBM's UDDI service yesterday and at least the web interface is by several magnitudes quicker (from here). I should probably play with their service a little to improve response times. ( ... just did, IBM and SAP aren't any faster)

Quick note: All of our *.newtelligence.net and *.newtelligence.com servers will be unavailable from 6PM CET until about 6AM CET due to construction work in the office.  

Sorted out. We educated the construction guy how to turn the servers back on. He succeeded. Obviously. (Just checked coming back from seeing Charlie's Angels for the second time. This time the English original. Fun movie. Guy movie. Most definitely.)

Category-based UDDI RSS search. Done.

Matevz Gacnik got it and put himself on the list 

(Note: I set the output cache to expire every 180 seconds and therefore it mostly takes a little while to rebuild by getting the fresh data from UDDI) 

I wrote a little OPML renderer that grabs all RSS feeds that are registered in Microsoft's UDDI registry

A quick overview about my changes to BlogX and why it just isn't BlogX anymore. And, yes, you'll get it.

Philip Rieck makes a great point about the obsession with "revolutionary innovation" quite a few people have. Little steps count too, he says, and there's good stuff in old things and I absolutely agree. At TechEd in Barcelona I said in one of my talks that people should read less computer books published in 2003 and more of those published in 1973.

Stephen Forte is a big fan of Munich, except for their Linux strategy; and I do agree on the latter -- for some obvious and some not so obvious reasons.

BloggerAPI, MT API, MetaWeblog API, Comment API, Pingback API, Trackback  ...  are you nuts?

I must admit that until last week I didn't really pay much close attention to all the blogging related APIs and specs beyond "keeping myself informed". Today I copied my weekend's work over to this server and now I have all of them implemented as client and server versions. Sam's and Mark's validator is happy with my RSS 2.0 feed and the experimental Atom (Pie/Echo) feed.

I have to say ... the state of affairs in this space is absolutely scary. Most of the specs, especially for the APIs are lacking proper information detail, are often too informal with too much room for ambiguities and you need to be lucky to find a reasonably recent one. Sam laments that people don't read specs carefully and I agree, but I would argue that the specs need to be written carefully, too. It also seems that because the documentation on expected behavior is so thin, everybody implements their own flavor and extensions and not only do the APIs have huge overlap, but it seems like any random selection of offline blogging tools will use its own arbitrary selection of these APIs in any random order. Since my implementation didn't "grow" over time, but I implemented it all in one shot essentially only since last Thursday and had to look at this all at once and what I found was just saddening. All of this has to be consolidated and it will be.

I am all for the Atom project and creating a consolidated, SOAP-based API for all blogging functions that the aforementioned APIs offer. XML-RPC was a good thing to start with but its time is up.  I am also for replacing RSS x.x with a spec that's open and under the umbrella of a recognized standards body and not of a law school, that's XML as of ca. 2003 and not as of ca. 1998, and that's formally documented (with a proper schema). What's there right now smells all like "let's hack something up" and not very much like serious software engineering. Ok, it's proven that it all works, but how about dumping the prototypes now?