This past week we released our second Silverlight 2 component, Xceed Real-Time Zip for Silverlight. Our first Silverlight 2 component, Xceed Upload for Silverlight, was the industry’s first commercially available control for Silverlight 2. I think it’s great that we’ve been first to release a component for many of Microsoft’s new development platforms in the past 10 years:

·         1st .NET component (Xceed Zip for .NET, alpha, Nov. 2000)

·         1st WPF component (Xceed DataGrid for WPF, RTM, Jan. 2007)

·         1st Silverlight 2 component (Xceed Upload for .NET, RTM, May 2008)

·         1st Workflow Foundation activity (Xceed Activities for WF, RTM, Apr. 2007)

·         1st Biztalk Server 2000 component (Xceed FTP for Biztalk, RTM, Jun. 2001)

·         1st .NET Compact Framework component (Xceed Zip for .NET CF, Beta, Apr. 2003)

And, I couldn’t confirm this through Archive.org, but I seem to remember Xceed being the first to release a 32-bit OCX during the changeover from 16-bit OCX components to 32-bit ones about 12 years ago. By the way, our domain name back then was xceedsoft.com.

Back to Xceed Real-Time Zip for Silverlight, what’s great about this product is that it compresses files or streams into Zip archives and decompresses Zip archives in a streaming fashion without using intermediate disk/memory storage or temporary files. That really jives with the likes of Silverlight, which doesn’t allow local write access.

Why is it called “Real-Time Zip”? Not because it is faster, since it avoids disk writes, but because it starts outputting a Zip file as soon as the first bytes of the first file to compress are provided.  In the same way, it can also start unzipping a Zip file as soon as the first bytes of the Zip file are available. By the way, the size or number of files to compress or uncompress has little bearing on the memory footprint. You can Zip many multi-GB files without worrying about memory, though if you are Zipping tens of thousands of files (regardless of their size), memory use might start to become be a factor. The component must keep some information (filename, path, checksum, size...) about each file in memory in order to be able to write the Zip file’s “central directory” portion at the end of the Zip file.

I should also mention that strong 128- to 256-bit AES encryption is also supported while compressing/uncompressing.

What use is there for a Zip library with Silverlight you might ask? First, it will let your Silverlight application read and consume the contents of a Zip file that’s stored on your user’s local filesystem. In the same fashion, it will allow your app to receive a Zip file from a server and unzip and consume the contents as the Zip file is coming in over the wire. Second, it will allow your code to compress a bunch of user selected files from their local filesystem into one Zip file that you can start uploading to a server or another user even before the complete Zip file is ready.

Well, hope to see you at next week’s PDC 2008 event, where Xceed will be dedicating the our booth to exhibiting our advanced datagrid for WPF.

Odi