Jon Udell writes in his most recent column that some think that there is a "controversy" about the use of XML namespaces. This seems to stem from the sad fact that RSS never got a proper namespace assigned to it and is one of the hottest schemas specs in the XML space right now. Sorry, there may people in disbelief, but the XML Namespaces spec is normative and referenced in the current XML 1.0 (Second Edition) spec. The empty namespace is a namespace.
Some notable experts — including Sean McGrath, CTO of Propylon in Dublin, Ireland — argue that namespaces should be avoided for that reason.
You can't avoid namespaces, they are automatic if you use XML today. If you don't declare one for your vocabulary/schema, you are contributing to a large cloud of "stuff" sitting in the "not part of any" namespace. The "empty" namespace (which essentially says "not part of any namespace") is the XML equivalent of a the "these are just some tags" garbage dump.
My buddy Stephen now also runs dasBlog in "all features enabled" mode. Both of us are now using our Radio subscriptions, while they last, just to upstream our RSS feeds to the Userland cloud from dasBlog. His Radio feed is in sync with the new feed and so is mine.
John Bristowe is also a Radio convert and comments that exuberantly with "Free at last, free at last, thank God Almighty, I'm free at last.".
I guess we can sum this up with:
Dear Userland, for more than year you didn't even bother to try fixing all the substantial problems Radio has around random upstreaming failures, random crashes, losing content, whacky caching effects, broken comments, lack of extensibility with mainstream tools and a lot more things. Radio is stuck at version 8.0.8 in a time when a new blogging tool gets published every other day. This is our answer.
I've written a bunch of features in dasBlog specifically to give myself a clean upgrade path from Radio to my stuff (and some of them I still have to document cleanly). Whenever anyone hits a permalink at my old Radio site, they get redirected to the correct entry here, I can update my rss.xml at the Userland cloud and I can use any available Radio design templates pretty much unchanged. What's funny, for instance, is that my engine pretty much never fails with a timeout when upstreaming the rss.xml to the Userland cloud. These are the real reasons for why dasBlog does what it does. I just got totally fed up with Radio.
John Bristowe wrote me a "Thank you" email saying "I believe a "switch" campaign (a la Apple) is in order. Goodbye, Radio. Hello, DasBlog!  ".
There's certainly not going to be a campaign, but I'll happily share my config details with anyone who's asking. Sorry, Userland.
Today was another day of brutal heat. Nearly impossible to go outside during the afternoon. So I had a very lazy start into the day and then watched football (real football!) and observed the players getting grilled ;)
My team, Borussia Mönchengladbach ended up with a 1:1 tie against Werder Bremen, scoring in the 81st minute to equalize a Bremen penalty goal earlier in that half. Two games, 4 points and rank 5 in the league with ranks 1-4 having the same point score. Not bad at all for this year's start. I rarely ever have time to go to the stadium, but I have been a huge fan ever since I could kick a ball. It's my home city club, so we're talking love here, not just sympathy.
Anyways ... between breakfast and football I played around with CSS and created a new template for my own blog, trying to stop myself from jumping into the code-base and making adjustments. Then I dropped the 5 files onto the server some 15 minutes ago and .. voilá ... works. The theme uses IE filters for the shadows, but otherwise it looks the same in Opera. Haven't checked out other browsers, but, in all reality and honesty, and looking at our server logs .... 'nuff said.
Version 1.1 of dasBlog is up for download. Preferred download source is the GotDotNet workspace for the project, the other is on our server here.
With this drop, we’re also releasing the lock on the source and leave the files checked-in in the workspace. If you want to add stuff, you are invited to do so, but make sure you read the set of simple rules I posted there on how to deal with the source control system.
|
He's an author and a great speaker, he was one of the best known technical consultants at Microsoft Germany and he initiated the "MSDN TechTalk" event series. His in-depth knowledge of Win32, COM and COM+ is astonishing and the same goes for the dark corners of the .NET Framework. With this, and a lot more things I could mention here, he's already a "software legend" in the German developer community.
... and now he made a very newtelligent move and joined our team. Welcome on board at newtelligence AG, Michael Willers. |
 |
Jörg ist current checking out dotText. He very much likes the admin interface and says it's very cute. And not only that. I had a glimpse and I have to agree. I think it's fantastic that Scott and us are releasing such big chunks of public code for the same purpose at the same time, but there is no "vs.". I think .Text is cool.
The most striking between the two engines is that .Text sits on SQL and ours uses plain text files. What I found through the email feedback I've gotten is that a lot of people who want to use dasBlog have their stuff sitting at some ISP and either don't have a SQL Server to talk to or the setup is too much of a hassle. So for them, the plain text storage makes more sense. I was about to rip it out and replace the file storage with a SQL backend as well, but now I am quite happy that I didn't.
(Although i have to admit that the transaction-loving architect in me still opposes the whole idea of using plain text files for read/write in a concurrent environment)
The second difference is that I started the whole thing only a bit more than 3 weeks ago from a copy of BlogX.
James Avery suggests creating something new for topic-based aggregation. His idea is to allow aggregation of blogs by topic and not by person and wants new things invented for this.
I think they exist.
The item-level <category> element of RSS allows for setting a taxonomy on category items and that's sufficient to make James' idea work, if (a) aggregators were looking for the domain attribute and allowed grouping by it and (b) blog engines would allow you to attribute your categories like that. Then, we "only" need to agree on common categories (or someone just writes some up) and were set. No need to register anywhere or with a central system. Here's an example of how the elements could look for .NET bloggers:
<category domain="urn:msdn-microsoft-com:netframework">ASP.NET</category>
<category domain="urn:msdn-microsoft-com:netframework">Enterprise Services</category>
<category domain="urn:msdn-microsoft-com:netframework">C#</category>
<category domain="urn:msdn-microsoft-com:netframework">VB.NET</category>
<category domain="urn:msdn-microsoft-com:serversystem">SQL Server</category>
<category domain="urn:msdn-microsoft-com:serversystem">BizTalk Server</category>
No, I haven’t built the stuff 3219 times. It’s “3” for 2003 and “219” is today’s day of the year. Here’s the compiled one-liner that sits in my system32 directory and tells me …
Download: buildday.zip
I can’t myself to write the release notes at this hour (and the folks already running V1.0 would be unhappy without them), but dasBlog 1.1.3219.0 is sitting here all wrapped and packed and ready to go. So expect the zip files to show up at some time Friday at GotDotNet and around here. To start, here’s a bit of new documentation for the themes, templates and macros.
The documentation hero for the macros (and especially for digging up all the CSS classes) is Jörg Freiberger.
Jörg also spend numerous hours figuring out how to trick the ASP.NET calendar control into things it just doesn’t want to do in terms of formatting. No matter what you do, it just keeps injecting style attributes for things it seems are right although nobody ever asked for them. So the calendar control got us annoyed enough that we told it to shut up about formatting by creating a derived control and overriding the Render method like this:
protected override void Render(HtmlTextWriter writer)
{
StringWriter sw = new StringWriter();
HtmlTextWriter hw = new HtmlTextWriter( sw );
// Render the calendar by calling the base class' method.
base.Render(hw);
// strip all the calendar formatting.
writer.Write(Regex.Replace( sw.ToString(),"\\s*style=\"(.*?)\"",""));
}
It is brutally hot here. Mid 90s(F) or always more than 33°C every day. No clouds. For at least 5 days already. Forecasts say that the day temperatures won’t drop for another 4-5 days. This is the middle of Europe but it feels more like North Africa now. It’s rare that people have air-conditioning in their homes, since we usually get like 10 days above 30°C in a whole summer. So everyone’s sweating.
This morning I went to the local Microsoft office in Neuss (some 15km from here) for a customer meeting. They don’t have air-conditioning, either.
newtelligence does 
Being cited
by Sam Ruby is starting to look like a (much less devastating) version of
being Slashdotted. Thanks
for helping test my asynchronous, queued referrals processing.
I absolutely think it is a silly idea blogging this, or even filling out the questionnaire in the first place, but I have quite a few friends and colleagues of whom I just know that they'll agree so wholeheartedly with this oracle's ruling that I must blog the result:
Which OS are You?
If you look at the bottom of the webpage of this posting (at least at the time of this posting), you'll see that this is now running on build 1.1.3218. The CSS styles of the templates here haven't been updated fully, so the calendar on the right is a bit ugly and I have disabled all other themes for the moment.
If you compare this (rss.xml at my old Radio weblog) and this (the RSS feed here), you'll notice that they're synchronized now. (Welcome back to my blog to all those folks still subscribed to the Radio feed)
This here  was typed as colon-dash-caps-D and is converted to an image link when rendered to the website using a simple content filter. All of you reading this through an aggregator will say "really?!", because all you'll see is colon-dash-caps-D. I don't want all that traffic for the images coming this way. ;)
According to InfoWorld, SCO wants to have $699 per
processor from everyone who runs Linux on a server, as an “introductory”
offer and will ask $1399 after Oct 15 for a single-processor license.
That’s pretty stunning. Even if SCO were right with their allegations
that there is SCO-owned IP in Linux (and I am not in the position to make any
statement about the rightfulness of that claim), $699 per processor is still well
above and beyond what would be their fair share – that pricing scheme
looks more like “this is our OS, including everything that ships with it”
and that seems just plainly wrong.
This reminds me of a similar high-profile case: the Unisys GIF license. They
hold/held the LZW patent and that’s used in GIF. Of course, lots of
developers found out after they’ve implemented and shipped GIF support
and Unisys probably waited for a critical mass to accumulate before they
started enforcing licensing fees for that patent in early 1995. (Side note from
the Unisys site: The
U.S. LZW patent expires June 20, 2003, the counterpart Canadian patent expires
July 7, 2004, the counterpart patents in the United Kingdom, France, Germany
and Italy expire June 18, 2004, and the Japanese counterpart patents expire
June 20, 2004.). While Unisys certainly didn’t make too many friends
with that move, they were initially asking something like ten cents to at most
ten dollars per distributed copy of any software package using the GIF format,
if I remember right (the pricing information seems to have vanished). I would
think that looking at the SCO case, this all of a sudden becomes very fair and
reasonable.
[Still, the web-site fee of $5000 per site if you were/are using unlicensed (as
in: Unisys’ LZW patent licensing) software to create your GIFs, remains outrageous]
Jörg and myself are getting real close to release the new drop of our "summer project", dasBlog, within the next two to three days. It's going to carry a 1.1 version number already, because we've made another set of massive changes, including restructuring the code base and splitting it up into many more files and projects, which should make collaborative work on this much easier (...possible).
Areas that were worked on specifically:
- All controls we render inside the macros will get a CSS class assigned to them and we are removing most of the fixed formatting inside the code, so that the appearance of every little thing shall be customizeable. This will have an impact on existing templates and may break some of the Radio templates, but the required changes should be rather minimal.
- All time expressions are now consistently stored in UTC
- Mail-To-Weblog can now deal with RFC2822 dates
- Nested OPML outlines can be rendered and edited
- "Content filters" is not a new, but now visible feature that allows to run an arbitrary number of search/replace filters (regex or plain) against content before it is rendered. So, if you want to turn semicolon-dash-closing-parenthesis into a smiley when your page is rendered, you can add a filter that will do so.
- dasBlog can post its own RSS feed to any remote storage system supporting the XmlStorageSystem API, including the Radio Userland store.
- Lots of additional configuration options to switch services on and off.
- Several bug fixes.
Once we're done with that, Stephen Forte has promised to add some additional caching magic to the stuff.
My Radio subscription runs for another 11 months and I have some 40MB of webspace there, so why not use it. Also, it seems that it's going to take forever for people to switch their subscriptions from the old RSS feed to the new one. So, I wrote an XML-RPC client for Userland's Radio cloud this weekend and a little command line utility for upstreaming stuff outside of Radio. Of course, the real reason for the client piece is to be able to have my blog engine automatically push changes in the RSS feed up to my old blog location for as long as the Radio subscription runs, so that even the lazy folks get the right stuff. It'll be a switchable option in the next public dasBlog build.
(For a change, an entry in German and on something totally different)
Heute abend ab 18:10 Uhr ist die Bundesliga wieder "zu Hause" bei der ARD Sportschau und beim WDR. So sagt zumindest die Werbung. Für mich weckt die Rückkehr der Sportschau zum WDR "nostalgische Erinnerungen". Und zwar nicht nur aus Zuschauersicht, sondern an die Zeit, als ich beim "Machen" der Sportschau (in "tragender Rolle", nämlich als Kabelhilfe) für rund 6 Jahre, von Mitte 1985 bis Ende 1990 als Schüler und dann als Student dabei war.
Mitte der 80er war Fußball für die Volksseele zwar schon so wichtig wie heute, aber im Fernsehen fand Fußball eben lange nicht in dem Ausmass statt wie heute. In der Sportschau gabs drei oder vier Spiele in Ausschnitten zu sehen, und vielleicht noch die Tore von den anderen (wenn man Glück hatte) und an Kameraperspektiven gab's eben auch nicht so viele. Üblicherweise gab's eigentlich nur drei bis vier Kameras bei einem normalen Spiel. Eine "Führungskamera" für die Totale, dann entweder jeweils eine auf der Tribüne auf Höhe der jeweiligen 16 Meter Linie oder eine weitere Kamera unterhalb der Führungskamera und eine Handkamera für Interviews. Und das Zeug war schwer. Damals war das alles noch gute, alte Analogtechnik und wog ein mehrfaches dessen, was die heutigen Digitalkameras wiegen. Und wir mussten das natürlich alles durch die Gegend wuchten und für jedes Spiel kilometerweise Kabel ziehen. Auch war es damals absolut nicht selbstverständlich, dass der fertig geschnittene Beitrag einfach per Richtfunk (oder über Satellit) übertragen wurde. Wenn, und das galt besonders für die Sonntags-Sportschau, genug Zeit zwischen Aufzeichnungsende und Sendung war, ging das Band per Motorradkurier nach Köln.
Alles das war eine fantastische Zeit -- und der beste Studenten-Nebenjob, den ich mir vorstellen kann. Ich war jede Woche bei mindestens einem Bundesliga Spiel, oder mittwochs bei UEFA Cup, Pokal der Pokalsieger, beim DFB Pokal, der Fußball EM 1988, vielen Playoffs der Eishockey-Bundesliga, mehrmals beim World-Team Cup Tennis, Tischtennis WM 1989, diversen Leichtatlethik Meetings, und so ziemlich bei alle anderen Sportarten die man sich vorstellen kann. Und mit 130,- DM pro Tag und 50% Sonntags- und 100% Feiertagzuschlag war der Spass auch noch richtig gut bezahlt (für die damaligen Verhältnisse).
Einige der damaligen Kabelhilfe-Kollegen sind beim Fernsehen geblieben und teilweise auch vor der Kamera zu sehen. Tom Lehel, zum Beispiel, ist momentan in jeder zweiten Comedyserie am Start und Andreas Sauer ist mit der Band Leo Colonia eine grosse Nummer im Kölner Karneval. Und diverse bekannte Sportredakteure haben just damals beim WDR angefangen, waren als Studenten MAZ Redakteure (d.h. haben während der Ausziechnung Timecodes mitgeschrieben) oder haben auch Kisten geschleppt. Und Herr Guten Abend Allerseits war auch schon damals Redaktionsschef.
A good deal of yesterday and some of this morning I've been fiddling around with nested ASP.NET DataGrids. Binding nested grids is pretty easy and they show all you want, but editing items in a nested grid just doesn't work as easy as editing in a simple Grid. In fact, it doesn't work at all. What happens is that you can put a nested grid into edit mode, but you never seem to be able to catch any Update/Cancel events from the edited item.
I tried to look for a solution by asking Google, but the answers that I found were very unsatisfactory, since there was no explanation on why exactly it doesn't work. So, here's why ... and it's very, very simple: Nested DataGrids lose all of their ViewState on any roundtrip. That seems to be some sort of problem that's actually related to how the entire TemplateControl infrastructure works, but that's what it is.
Since that's the case, the EditItemIndex isn't preserved across the roundtrip and the DataGrid doesn't know how to dispatch the Update event. Now, how do I work around it? Again, pretty simple: You need to store the EditItemIndex (and SelectedItemIndex, etc.) of the nested data-grid in the Page's ViewState whenever they change (Edit event, Cancel event, etc.), keyed by the UniqueID of the DataGrid and a matching suffix. When you reload the sub-grid on a roundtrip, recover the value(s) from the ViewState of the page and DataBind().
I've put the workaround into my current working copy for dasBlog (the OPML editor gets a hierarchical editor now) and it works great. Next build that gets released, you can look at it.
|