Office 2007 SP2 reduces interoperability – tough luck?
Jeremy Allison over at ZDNet has just posted an article where in a nutshell he states that Microsoft broke the interoperability of the ODF format between Office 2007 and other implementations of this format. According to this gentleman, the guys over at Microsoft are mean little bastards because they implemented the ODF standard verbatim. Whoa, whoa, whoa little Timmy!
Last I checked, there was a war going on towards Microsoft because they were mean chauvinistic bastards who insisted on not making Internet Explorer more standards compliant, because the standards were the way to go and anything other than the standards just breaks pages on browsers that implement the standard. I totally agree with this point, but by the same measure, I have to disagree with this ODF quarrel.
With SP2, Microsoft implemented the ODF specification to its fullest. Then there are other implementations like OpenOffice's that have additions to the specification, but that aren't part of the standard! Yet, it is Microsoft that people come out to the streets to criticize, and not the people who engineered a poorly designed standard. Please, don't take me wrong. I am also against OOXML, but that doesn't mean that the alternatives are perfect and perhaps Microsoft is just proving a point amongst narrow-minded people who don't care for a little reasoning.
Want spreadsheets to properly support formulas in ODF? Make it part of the friggin' standard! Don't expect Microsoft to deviate from the standard for interop's sake, especially now when you have before criticized the company for not being standards-compliant.
My bottom-line is: who is to decide whether a standard should be implemented in a strict manner or not? And to which extent should interop efforts be made? All in all, if Microsoft designs interoperability towards OpenOffice, it might just break things with another Office Suite that decided to implement things differently.
PasteBins – Usenet 2.0
Here I am again with a crazy project of mine: HaxTools.
Ok, the name wasn't particularly well thought but I think you will find the idea quite well engineered.
On a little background note, let me introduce you to Usenet. Usenet started off in 1979 as a forum-like service. It was a discussion board were allowed to discuss and share opinions, very much like forums as we know them nowadays. Instead of using your webclient, you would have to use an e-mail client with support for NNTP (the newsgroups protocol) or an actual application dedicated to newsgroups, this means that this service, unlike forums, doesn't work over HTTP but over a different protocol, NNTP.
What happened after was that people realized the potential of the newsgroup servers for other purposes, namely file distributing based on a centralized server (as opposed to peer-to-peer). Such newsgroup servers are most commonly provided over very powerful Internet backbones which makes them great platforms for distributing all kinds of binary files to several people just at the cost of one single upload.
And so it started happening. Programs were developed that were able to post binary files on newsgroups, and newsgroup clients that were able to download binary files also started showing up. From posting innocent files to using Usenet as a gateway for piracy was quite a small leap and nowadays one could say that the Usenet is perhaps most used for illegal content than for actual discussion of ideas.
Now, back to my application. HaxTools is a proof of concept set of tools; therefore, I won't be liable for any damage it causes to your computer or to whatever uses people give it. In principle, the program does not violate any terms of service, although it is likely that the service it uses currently (http://rafb.net/paste/) will get up measures to fight it.
My application makes use of PasteBin sites (like the RAFB.net) to store files online. The HaxUploader allows you to choose the granularity of the upload up to 500Kb (meaning that your file will be sliced in 500Kb pieces) and allows files of up to 10Mb - this limit is in place so that your computer doesn't crash. This is just because I had no concern with optimization, so all operations are done in memory, which can be cumbersome on the computer for big files. However, optimizations can indeed be made so that all operations are done out of the hard drive, making the process slower but workable for bigger files. Depending on the success of this proof of concept, I may get into optimizing the idea.
How does it work from a user's perspective?
Nothing simpler. The user chooses a file on HaxUploader, presses upload and waits until the green bar gets filled completely and links show up on the box below. When the links are there, you just have to copy the said links (don't ever change the order!) and distribute them to other people.
From the receiver's perspective, they will open HaxDownloader, paste in the links on the SAME order as they have received them and press Download. After a while, a message will appear saying that the process was completed; at this point, on the same folder as HaxDownloader was ran, there will be a NewFile.bin - this is the standard name for all downloaded files. Afterwards you'll have to rename it to whatever you like and also keep in mind that you do have to change the extension of the file to what it was originally - this is also something that could be done better in an actual program.
After that is done, your file is ready to use. Whether it is a RAR file, or an MP3... whatever, it will work with all file types and we'll now get to how it works from the code's perspective.
What's the whole idea? In a nutshell, the HaxUploader grabs the file it is meant to upload, streams it into memory (treating it as a binary file, thus working for any kind of files) and then moves on to convert the file contents to Base64. This is the standard format on which files are stored on Usenet; so the core idea is kept. With the contents on Base64, it goes on to split them into smaller chunks (given by the granularity setting) and uploads each of the chunks into a separate 'pasting'.
When it has finally submitted all the parts and acquired all the links from the 'pastings' we're all done and it simply outputs the links to the user.
The order in which the links are arranged does matter and it is imperative that they are kept in the order they are provided to you, otherwise it simply won't work as I haven't put in place any order measure. (It can be done though and on an actual application this would be needed).
The Downloader program simply fetches the content of the paste links, puts it all back together and decodes the Base64 string into binary, recreating the file.
As a final note, there isn't a big deal of protections and validations in place, that is why this is a proof of concept - I just wanted to prove that it can be done.
For now I am not releasing the source code but just the binaries. If you are interested in the source code, you can contact me at tiago[at]espinhas[dot]net and we can discuss the situation.
Until the next time!
A personal view at Firefox vs. Chrome
So, really, now that the hype is over, what is the browser of choice? Well, the out of the box answer for me is Firefox but let's have a deeper look at the contest shall we?
What plays in favour of Google Chrome?
I for one really enjoyed the looks. It has a clean and sleek interface without your regular toolbar menus and without a caption bar. I find this amazing. It's the first browser that was designed with true usability in mind regarding the menu paraphernalia. The guys at Google really are being serious about seeing websites as actual applications, and proof of that is the fact that you can create "application links". This also plays in Chrome's favour in my opinion. There are pages that I simply have open at all times and ones that I have to be able to access quickly; Google Chrome with this feature allows me to run GMail (or any other website) as a separate window, simply by leaving an icon on my desktop. This separate window is also special, it has kind of usability on steroids since it has no menu whatsoever. It does have a caption, which in this case is good because I might want to move the window around while not maximized.
Ok, now that we're done talking about the user interface, we go on to the actual features. For starters, let's face it: Google Chrome is fast. Actually, it feels faster than Firefox as far as browsing is concerned. How do they achieve it? I'm not exactly sure and if my suspicions are right, you can probably achieve the same effect with FasterFox or with a properly configured Opera, but I'm dealing with the facts here and that is that Chrome feels fast.