Linked by Thom Holwerda on Fri 14th Jul 2006 21:08 UTC
Microsoft In a Q&A, Neelie Kroes, who fined MS for not complying with the EC's antitrust ruling, said: "I regret that the Commission has had to take such a step today, but given Microsoft's continued non-compliance to date, I have been left with no alternative. Today's decision reflects my determination to ensure that Microsoft complies with its obligations.Microsoft has claimed that its obligations in the decision are not clear, or that the obligations have changed. I cannot accept this characterisation - Microsoft's obligations are clearly outlined in the 2004 decision and have remained constant since then."
Permalink for comment 143399
To read all comments associated with this story, please click here.
From the mouth of Samba's Jeremy Allison
by MollyC on Sun 16th Jul 2006 01:21 UTC
MollyC
Member since:
2006-07-04

Here's what Jeremy Allison, of Samba, had to say regarding this matter:

http://www.theregister.co.uk/2002/03/19/why_microsofts_eu_concessio...

"There can't be a specification that's worth anything," says Jeremy Allison, joint lead of the Samba Project. "The source code itself is the specification . The level of detail required to interoperate successfully is simply not documentable - it would produce a stack of paper so high you might as well publish the source code."

Now you see why it's been difficult for Microsoft to document a "protocol" that would satisfy the EU, and why Microsoft offered the source code.

Oh, I also read that the EU is pissed that Microsoft "included [sic] several hundred pages detailing how to handle errors, while failing to document how the errors happen." Look at almost any API documentation, and you'll see that the documentation regarding errors is brief. Errors can happen for any number of reasons (low memory, network disconnects, etc). The idea is for a component to notify the caller of the error by throwing the appropriate exception or returning the appropriate error code, so that the caller can deal with it gracefully, regardless of exactly how the error occurred. Pages and pages on how/why errors might occur is foolhardy and leads to more bloat in the spec. Some errors do need such documentation, the vast majority do not.

Reply Score: 1