“Any sufficiently awful stupidity is indistinguishable from malice.”

Ok – in the mean time I’ll write to Florian to see if he knows something.

:o)

/Jesper

Do you have a link to a development page of the Novell converter not using XSLT? Do you know how far they are in the development?

Thanks,

Jesper

RTF has a standards history that looks like a rehearsal of OOXML.

Quote from GrokDoc:
http://www.grokdoc.net/index.php/Dirty_Tricks_history#RTF
[
Sadly, RTF is not a reliable standard. Why? Because its main purpose seems to be to provide seamless compatability between versions and OS platforms of Microsoft Word itself. It is routinely updated with every new version of Microsoft Word. It has never been proposed to ANSI or the ISO or any other standards group for peer review. It is 100% Microsoft.
]

Winter

Reports on RTF format file size, speed, compatibility would be welcome… just ask Novell how it feels about having RTF as an interoperability format.

Interesting fact is that Sun’s ODF Plugin for Microsoft Office loads the test file 17x faster than Microsoft’s Add-in for ODF (30 seconds versus 516 seconds). Same file, same version of Microsft Office. But Microsoft’s Add-in is 17x slower. What’s up with that?

I would bet that the real reason ODF compresses better is that tags like o:p (IIRC) don’t make it into the Huffman coding (which typically will have a minimum number of character cutoff) while the more verbose tags of ODF will be Huffman coded.

Of course, I’m using terminology from rusty memory, so I might not have the terms right, but the idea is the same :)

Also, Microsoft has some of the best developers in the business (along with some bad ones, I’m sure). Unfortunately they are usually tied down by corporate policy and thus can’t always work to the best of their ability. So I wouldn’t, in general, blame MS developers for problems like this.

In any case, my understanding is the Add-in is a lot of XSLT with a little C#.

There also appears to be a lot of hits to temporary files on disk. That can’t be helping.

CN=Rob Weir/OU=US/O=IBM

The connector, needing to deal with emails where the From and CC lists were all in this format, obviously needed to translate those names into a simple common name format.

A no-brainer, right? You just take everything to the left of the “/” character, and to the right of the “=” character, right? This would take about 2 minutes to code.

Not according to Microsoft.

MSFT’s thinking was “the common name portion of a person’s name is typically the second entry in their alias list in the Domino directory. So we’ll look it up.”

For each name listed in the From or CC list, Outlook queried the directory on the server for the complete alias list, and then took the second element in that list. This meant that reading an email from a Domino server in the Outlook client could easily have 10 times the network impact of reading that same email from an Exchange server.

You can imagine how performance suffered as well.

Of course, there’s no rule that says the second entry in the alias list actually has to be the common name for that user. That’s how I discovered the behavior in the first place — because one particular user had an alias of a former employee in the alias list, so all messages appeared in Outlook as if they were coming from that former employee.

Who in their right mind would choose to perform a database query for each and every name in an email instead of simply parsing a string?

The answer: no one. It was obviously a feeble attempt to cripple the performance of the connector in order to make Domino look bad.

MSFT is, of course, free to code their own applications as badly as they wish. But I’ve always considered that example to be indicative of who’s interests MS holds dear.

Although it quite probably *is* part of their marketing engine (e.g. along with all the warnings about format conversion), it could just as easily be an economic or technical reason. i.e. the first version that does the job might not be the fastest, but there is no incentive to put any more work into it. It may also be that the internals are so strictly optimised for the current version that it is just difficult to make it work – but an order of magnitude difference or more stretches the credibility of this quite beyond breaking.

With the ODF plugin, perhaps they ARE using xslt translation. XSLT is a dreadfully slow and terrible technical solution to the problem it solves – it easily runs orders of magnitude slower than custom code (which in many cases isn’t much harder to write in the first place). A typical computer science solution to an engineering problem – sounds good but just doesn’t work in practice.

However, I’d encourage everyone to try out Sun ODF Plugin for Office, much better:

http://www.sun.com/software/star/odf_plugin/index.jsp

Heck, even considering a simple matrix multiplication, which is conceptually just three loops and four lines of code, the implementations vary in speed by an order of magnitude mainly due to how efficiently the code exploits caches and pipelines.

- written in .NET, so incurs a few seconds just to load
- not written with performance in mind, meaning bad String use all over the place. Effect : many garbage collections, a big time consumer.
- inefficiency of the resulting translated file. To store strings and numbers, there are ways Excel optimizes it (shared strings, factorized floats, single precision floats versus double precision floats). This greatly impacts both the file size, and the time to open it in its native application.

-Stephane Rodriguez

Don’t forget that the corollary to the law you quote is that sufficiently stupid actions are indistinguishable from malice …

As for why Office sucks in terms of performance, that’s probably because there’s no money in it for them, so they let their worst coders work on it. They’re just stingy that way.

Never attribute to malice that which can be adequately explained by stupidity.

Come on, given that MS weren’t even capable of spell-checking or copy-editing the OOXML spec to a level that high school students would consider acceptably unembarassing, I consider it entirely possible that they’re incompetent enough to have this happen accidentally.

I know they won’t do it to you, but why not be kind, give them the benefit of the doubt, and just assume they’re a complete bunch of retards?