The first time I hit HttpHandlers, I really learned how to use them in Walther's Book -
ASP.NET Unleashed. I definitely consider this book a must-have for any ASP.NET developer...
I've been working with the GPL licensed SharpZipLib on a home project and I love working with the library. I previously used a commercial zip tool in C++ and this thing is much nicer to work with.
Similar to the last post where we're serving up a .png, we have another situation where we serve up an XML document that forces IE to host Excel to view the data. Since we're launching a separate window, I can't dump the document directly from the aspx page - that's where a handler comes in. Problem is that the document can be rather large - especially being stored as xml, but now I'm thinking I'll compress it using SharpZip and store it in the database and decompress it on the way out of the httphandler.
I came across a decent article in MSDN by Dino Esposito on using HTTPHandlers that I'm reconsidering for one part of our application.
In our app, I create a graphic depiction of products flowing through a plant using GDI+ and I apply an HTML Map overlay for linking and tooltips. When I first created the implementation, my first thought was to place the image in the database and use a handler to provide it on request from the client page. At that time, my concern was two-fold: (1) how big would the average image get in production and (2) how would the storage of binary data affect our application performance. I handled this problem by writing the graphic out to the file system on the server and linking to that picture on the <img> tag. Now I'm thinking I want to pull this into the app and store the images in the database because the .png images are typically less than 100k. I wonder if there are any good performance numbers or recommendations on how to physically implement this in SQL Server. Is my concern even legitimate?
It'll be nice to see the dynamic image control in ASP.NET 2, this is pretty simply stuff that should be relegated to the framework.