He [DG: Mark Thompson] added: "Creating a fully digital Britain is a public challenge the BBC must help to lead. It is a Britain from which the BBC, and only the BBC, can ensure no-one is excluded."

 [via BBC NEWS | Entertainment | BBC outlines 'radical' manifesto]

What rubbish. Or is (only) the BBC going to start providing broadband connections to all of us excluded from the digital revolution out here in rural land? Why do they keep having to say only the BBC can do such and such, why do they have to say the BBC will lead - it still doesn't seem to have learnt how to be a team player does it.

So what do the pictures above each of the express products tell you about the product and who you ought to be (or aspire to be) to use it?

There's a bit of noise about that Konfabulator are a bit miffed that Apple 'copied' their idea for some new bits of OSX. Funny, when Konfabulator came out I thought, yeah, yawn, Zeepe can do all that. Perhaps it is time we put together a portfolio of the sorts of things being done in Konfabulator (I thought it was being ported to Windows?), but done in Zeepe (weighing in at a rather slim 650K as opposed to 4.2MB).

RC2 of the platform SDK is now available.  Still in the ISO image format but it is now available for download here [via Windows XP Service Pack 2]

Looks like a Monday morning trip to my nearest 2Mb ADSL link is called for

Async callbacks in server controls. ... I think callbacks have the potential of enabling a whole new genre of smart Web applications. .... [via Nikhil Kothari's Weblog]

Interesting that a bit of MS might be interested in a "whole new genre of smart Web applications" when others are just repeating the mantra "smart client, smart client, smart client".

But. It amazed me that ASP.NET ever made it out the door without this sort of feature. The origins of Webservices/RPC were for this sort of thing and it amazes me people can write articles implying they have moved forward the art when this really is very old hat, core stuff and should have been in ASP.NET 1.0. I was beginning to suspect that is wasn't in 1.0 because of a deliberate attempt to hobble web app development in favour of WinForms - good to see it will appear in ASP.NET 2.0 (the trouble is, we still have a long while to wait).

 

Jupiter recommends that software vendors channel their attention toward usability issues [via Jupiter Research Sees a Return to Rich Client Applications]

Lots and lots of noise around this issue at the moment, with a lot of noise saying throw away the browser and go for .NET or throw away the browser and go for Java, or throw away the browser and go for Flex.

At the moment, I don't see .NET (1.1) as a viable proposition - if nothing else, installation of an app is just too painful. Java, hmmmm, well Java has really never quite made it and Flex still hasn't got over the really bad developer environments there used to be for Flash. But, whilst I agree that throwing away the browser is a good idea, you don't actually have to throw away the underlying technology....

There is a ton of richness in html; simply moving to WinForms or whatever is not going to solve usability problems, that is down to app design. What I do agree with is that browsers make lousy frame windows for a lot (but not all) web applications. Zeepe solves that (and other) problems while maintaining the knowledge investment in html development.

Jeff Davis provides Details on pop-up blocking in xp sp2 rc2 - and other bits.

Heads up: CoInternetSetFeatureEnabled has changed significantly in RC2 over previous releases.

Without another SDK drop, testing this stuff is a bit difficult. Perhaps it has appeared somewhere I haven't noticed but I haven't seen anyone blogging from the IE team  mention these changes either. Can't be bothered to chase around in circles again on this.

Presumably the guys who write/wrote MyIE2 have all this stuff - if they haven't I hope they are jumping up and down (or perhaps they aren't going to use it, who knows, who cares?).

[Update - XP SP2 RC2 SDK not likely until July]

However he argues that not many people are using it (actually that not many desktop developers are using it) . There are two reasons for this which I know first hand as a developer of a desktop application that runs in the .NET Framework (RSS Bandit)

• The .NET Framework isn't ubiqitous on Windows platforms
• The .NET Framework does not expose enough Windows functionality to build a full fledged Windows application with only managed code.

Both of these issues are why Microsoft is working on WinFX. Again, the elepahant in the living room issue is that it seems that Microsoft's current plans are fix these issues for developing on Longhorn not all supported Windows platforms.

Disclaimer: The above statements are my personal opinions and do not reflect the intentions, strategies, plans or opinions of my employer.

 [via Dare Obasanjo aka Carnage4Life]

Stuff the disclaimer, bang bang from someone on the inside, lets re-iterate the major points here:

1. The .NET Framework does not expose enough Windows functionality to build a full fledged Windows application with only managed code.
2. Microsoft's current plans are [to] fix these issues for developing on Longhorn [only]

These are killer reasons for NOT developing in .NET (along with the other reasons I've been listing like p/Invoke, CLR->CLR breakage) that MS has to address.

A wild, but interesting response to Joel Splosky. generated this interesting response:

Interesting comments. I think the two of you are looking at things from two different perspectives. Joel seems to be approaching things from the shrink-wrap/ISV developers perspective where the combination of the size of the runtime, as well as certain immaturities exist in the platform (that can and does result in broken code) only serve to cause headaches and support work for a shrinkwrap vendor. If you approach this from a software services provider perspective, the size of the runtime doesn't matter and breakage is minimized by comporate controls and additional billable hours.  [via Seven Reasons Why the API War is Not Lost After All]

Bang on and in one.

There are also a couple of web app usability problems comments...

The main point I think Joel was making is that webapps will continue to become more and more prevalent, as opposed to smart-client apps, because users don't mind....I don't agree with this - webapps are loved by System admins, but users often just have them forced upon them and really dislike them. Just today, a Web project (ASP.NET) in my team in a very large corporation was rejected by users for being unusable. And this wasn't a fault with the app, which was as specified - it was the lack of those 'smart-client' features that the users are used to in Office, etc.

Personally I agree (or I'm glad there are some users out there who agree), I've always thought it problematic to do apps inside a browser, but I've not thought it problematic to do apps with DHTML technology. IMHO, XAML exists because the browser can't be developed without walking into a wall of security concerns and screams of non-standard etc etc. So, write a new browser using its own markup language. All markup can be implemented in a runtime that instantiates objects - its really a very very short distance to XAML.

June 17, 2004.  ... What are your ideas for improving the HTML/CSS/JavaScript infrastructure to make web app development better? Write them up and post them somewhere; I'll point to the best ones from my blog.  [via Joel on Software]

As usual, go read if you haven't. Key point: no point if users have to install something - i.e. no point in working on web apps unless you are a browser vendor. Quite probably reality, but a shame - dunno, needs arguing against somehow.

RISC OS rights rumble becomes war of words.  System builders suspend shipments [via The Register]

and rather quaintly called the RISC OS.

It had a really good idea for saving files (entirely drag and drop) but it didn't work that well in practical terms (you had to get the app window and filer window visible at the same time). Gosh, long time ago now.

Refining the Versioning Story.  

Wesner Moise reports on a talk that Jeff Richter did on the .NET versioning story in the Longhorn time frame. Some interesting quotes:

• "a library could not easily be updated since the CLR looked for an exact version match. There was a complex way to solve this problem through policy files; however, even engineers at Microsoft found this approach too difficult."
• "Microsoft has a new approach for Longhorn and Orcas (.NET v3.0), which divides assemblies into two categories, Platforms and Libraries."
• "Most assemblies will or should be libraries. Microsoft discourages the use of platform assemblies."
• "There are actually three types of platform assemblies: System-wide, process-wide, and app domain-wide."
• "Longhorn will no longer support multiple CLRs. Every managed application will be forced to use the latest version of the CLR on the system."
• "Whidbey is expected to include an Assembly attribute, AssemblyFlagsAttribute, which allows to developer to specify Library, AppDomainPlatform, ProcessPlatform, SystemPlatform, or Legacy to identify the versioning scheme the CLR uses to load a reference assembly."

I know that the existing versioning story doesn't cut it for a lot of folks. Will this new model solve the problems? Is there a complexity danger?

 [via Marquee de Sells: Chris's insight outlet]

This is what really annoys me. .NET is relatively new but was supposed to be the solution to all known problems. In particular, a major point was supposed to be the end of so called dll hell.

Already, we get "oops, that didn't work, even we didn't know how to make it work".

Even more scary, Longhorn will no longer support multiple CLRs. Now as far as I have seen, there have been breaking changes from CLR to CLR version - what the heck does this mean for vendors then? Perhaps (I hope) I am wrong on this point.

I keep thinking I really must abandon what I am doing and embrace .NET, this sort of stuff just keeps holding me back. Perhaps by v4.0 it will be stable and usable; it did take until Windows 3.11 until that was usable.

Well, Windows Update based installation failed with error 80240034 - that's it, no further information.

I was running XP under a Virtual PC and had restarted the Windows Update install a couple of times so perhaps it had got confused - a complete reboot and restart and Windows update deemed that it had .2MB missing. Having got that, it is now in the process of restarting after a succesful install..., there's a lot of Please wait....s during the restart.

 

 

The Reason for ATOM.  It seems to me that folks embrace ATOM mainly to get away from the guy that's credited with inventing RSS: "I'm not running for president.... I think a lot of people participating in this dicussion are not grounded in truth, deliberately so, openly so. Shame on you, I say."

This was said after he pulled down 3000 web sites he was hosting with no notice. ATOM is starting to sound more and more attractive... [via Marquee de Sells: Chris's insight outlet]

What is scary is this guy [Chris Sells] is respected and influential and yet apparently a data interchange format is attractive on the basis of the perceived behaviour of an individual. Oh well, politics is personalised, why not the merits and demerits of computer algorithms etc; we're only human.

"[T]he IE team does exist and does care".  Dave Massy is moving to Internet Explorer Program Management and wants to know what you want from IE in the next version. Don't be shy. [via Marquee de Sells: Chris's insight outlet]

Apparently Scoble jumped the gun.....