Archives / 2004 / January
  • Microsoft Win32 to Microsoft .NET Framework API Map

    Microsoft has released a Map of Win32 API calls in .NET Framework here. Worth a print out. This Map has Alphabetical Category List, Alphabetical List and a nice hierarchical list also. I found one thing missing here. There are no documentation links to these classes even though these classes have MSDN documentation.

  • Visual Studio .NET : a TOY? or a Machine Gun ?

    I am still wondering how many of a typical developer pool write thier own unit test cases for .NET.
    This is due to the lack of architectural background in many developers and great
    abstraction in Microsoft's technologies. Upto my observations, the Java guys are far ahead of these things since they have a large scope of error prone factor. The higher degree of abstraction spoils the developer's ability to build software by making him as an end user of the technology. But still there is an oppertunity to break that abstraction in .net. But the technology and tools like VS.NET hides that creativity and capability by doing more than enough.

    Though VS.NET gives more productivity by decreasing the work hours, It gives you a pipeline look, where you cannot think of other way also. e.g. In whidbey, you can get one DataGrid with Bi-directional sorting, Editable, Nice formatted features with out writing a single line of code. This kind of features will have a risky edge of making the new developers blind in coding. I have seen most of the developers putting blank feelings on faces for questions on internal things like this in my interviews.

  • HTTP Compression Explored

    Original Source :

    Compression is simultaneously one of the best-supported and most under-utilized technologies available on the Web today.

    The Technology

    HTTP 1.0 (1996) and HTTP 1.1 (1999) contain support for the "content codings" protocol parameter, the primary purpose of which is to enable compression of Web-based content without loss of data or change in its underlying media type. Since 1.1, HTTP implementations have routinely included support for all of the protocol elements necessary for reliable use of these content codings. Most major browsers like Internet Explorer, Netscape and Opera have supported compression since their fourth generation versions (roughly since 1998/9).

    At the HTTP level, compression is primarily supported through the use of a pair of HTTP headers: Accept-Encoding and Content-Encoding. The Accept-Encoding header is sent by browsers to indicate that they can accept a compressed version of the resource being requested, and to specify which of the commonly available compression formats they are capable of decoding. The Content-Encoding header is used by servers to inform browsers that the requested resource is being returned in compressed form, and to indicate which of the supported encodings was used to do the compression.

    The most common content encodings used for compression in HTTP are all based on the deflate format -- a combination of LZ77 and Huffman encoding (
    RFC 1951). The "deflate" encoding combines this deflate fomat with Zlib (RFC 1950), which adds the ADLER-32 checksum. GZip (RFC 1952), wraps the deflate format in a special header and a 32-bit cyclic redundancy check.

    The Benefits

    Any company with a Web site or Web-based application will benefit from using HTTP compression, whether self hosting or outsourcing dedicated Web servers from a hosting provider. Companies deploy HTTP compression for Web server acceleration, reduced bandwidth and faster perceived page load times for their end-users. HSPs generally leverage compression to reduce bandwidth expenditures.