Native code client coming for CardSpace as .NET runtime too demanding

I spoke this morning to Paul Mackinnon and Steve Plank at Microsoft, about Information Cards and CardSpace. CardSpace is part of .NET Framework 3.0 and higher. It enables uses to authenticate on web sites by presenting a virtual card, instead of typing in a username and password.

The CardSpace concepts strike me as sound, but as far as I can tell adoption has been minimal. I expressed my frustration; why is it that 18 months after the 1.0 release even Microsoft is not using it to any noticeable extent? I still see username/password dialogs whenever I need to sign into a Microsoft property like MSDN subscriptions or Live Mesh. Actually there is a beta service which lets you sign in with CardSpace – but I believe my point is still valid – how many people even know about this?

I was told that it is still early days and that we will hear more about the Live ID service when it comes out of beta. Mackinnon also mentioned that Microsoft is working on a native code client for CardSpace. Currently users need at least .NET Framework 3.0 which is a huge download and can be problematic. A native code client will be a small download with few dependencies. There is no firm date for release, though it is at least a year away (maybe previews before then).

Technorati tags: , ,

“ODF has clearly won” – Microsoft plays with fire

I was surprised to read that Stuart McKee, Microsoft’s US National Technology Officer, declared that “ODF has clearly won” at a Red Hat summit in Boston.

Open Document Format is an XML standard for office documents. Microsoft has its own XML format, called [Office] Open XML, and fought a bitter fight to get it standardised through ISO.

What’s a National Technology Officer? The role seems to involve promoting Microsoft products to government organizations. It is in the public sector that pressure towards standards adoption has been most intense. Presumably McKee is constantly having to defend Microsoft’s position. In May Microsoft announced that it will support ODF natively in Office, and will join OASIS to work on the standard.

Can Microsoft successfully promote its own OOXML standard, while simultaneously playing nicely with OASIS and ODF? The messaging, as PR people say, is tricky. Microsoft has told us that ODF cannot capture all Office documents with true fidelity, and that OOXML is more complete and better tuned for high performance. Can it now say convincingly that Office will be a great ODF editor? And if it can, surely Microsoft is undermining its own arguments for why OOXML was necessary in the first place.

Although Microsoft is fighting to maintain market share in the public sector by introducing ODF support, it still has a problem. ODF is closely associated with Open Office, and Microsoft Office is likely to lag its rival in this respect.

The real value of XML documents comes when you start manipulating them programmatically and on the server; I would have thought it would be difficult for Microsoft to make products like future versions of SharePoint work equally well with both formats. IBM’s server products will use ODF, which I presume is why the company fought brutally to oppose the standardization of OOXML.

In other words, a lot of future business hangs on this ODF vs OOXML argument. It is remarkable that a senior Microsoft person has said publicly, albeit in a small session at an open source conference, that “ODF has clearly won.”

Businesses and developers planning their future document management strategy can reasonably ask: is Microsoft still committed to OOXML? Does the format have a future?

I asked the company for comment and clarification, but as yet none has been forthcoming.

Technorati tags: , , , ,

Ruby interpreter flaws make the case for JRuby?

The official Ruby blog reports:

Multiple vulnerabilities in Ruby may lead to a denial of service (DoS) condition or allow execution of arbitrary code.

More discussion here and here. The community is fixing the problems energetically; but they do appear serious, and some are struggling with compatibility issues.

Since these seem to be bugs in the interpreter, it strikes me that this makes a good case for JRuby or in due course IronRuby, on the grounds that the Java and .NET runtimes are more mature. When I spoke to ThoughtWorks about its extensive Ruby work, I was told that JRuby is almost always used for deployment, partly because enterprises are more comfortable with it.

Technorati tags: , , ,