Followers of the IHttpHandler

LadyBug: They Listen!

Note: this entry has moved.

I highly encourage anyone playing with the Whidbey bits to take some time, register in the MSDN Product Feedback Center (a.k.a. LadyBug) and start submitting feedback. Based on my experience I can tell you that you won’t be wasting your time and you are going to get a reply to your submission, it may take a little while, but most likely you will get a response.

I have submitted a few bugs and suggestions myself (yes, I need to take some time, dig into my whidbey_bugs.txt file and start submitting those…) with different types of priorities and I was kind of surprised about how one of them turned up; I filed it as a ‘suggestion’ (‘bug’ was just too much for this one) and it is about a very low-level detail of the viewstate serializer that changed from 1.x to Whidbey in a way I didn’t like. My suggestion only received 1 (one) vote with a rating of 1/5. It was *my* own vote and I chose a rating of 1/5 because I thought “oh well, they’re in beta now, they’re surely worried by other most important stuff, so let’s be easy with them and just rate it with very-low priority”.

Sincerely, I was not hoping for this submission to get very far; luckily I was wrong!! :-)

I’m pasting a summary here (or you may want the real thing instead):

Problem Statement:  Opened by vga on 5/26/2004 at 4:10 PM 

=== Edited by vga on 5/26/2004 4:10:44 PM ===

There is a notoriously lack of support for the System.Web.UI.WebControls.Unit type in Whidbey.

In v1.x this type was assigned its own type code (49) which saved the serializer from having to store an –often large– string representing its assembly-qualified name.

In Whidbey, Unit is not backed up with a type code meaning that its full type name needs to be stored into viewstate, which means storing once the following additional string:

System.Web.UI.WebControls.Unit

Let’s take for example the following Unit instance:

Unit u = new Unit (“100px”);

In v1.x this instance will end up serialized into 8 bytes while in Whidbey final footprint will be of 39 bytes.

More info @ http://weblogs.asp.net/vga/archive/2004/05/26/WhidbeyWillBringsUsAShorterViewstateGuaranteed.aspx

Edited by Microsoft on 6/25/2004 at 7:05 PM 

Thank you for submitting this bug report. We are currently investigating the issue and will keep you informed of the resolution.

The Web Platform & Tools Team

Edited by Microsoft on 6/30/2004 at 4:25 PM 

The Microsoft Sub-status is now "Working on solution"

Resolved as Fixed by Microsoft on 7/22/2004 at 7:06 PM 

Thanks for the feedback, we've now added the Unit token.

The Web Platform & Tools Team 

As you can see this was “Resolved as Fixed” which means they’ve modified the current bits to add support for the Unit token, *way* cool!

Now, look at the dates and pay some attention: my initial submission was made on 5/26/04, almost a month later, on 6/25/04, they said “we’re investigating the issue”; my reaction to this was “oh sure… I can see the ‘thanks, but we’re a bit busy on other stuff’ already…”. Then, on 6/30/04, exactly 5 days later, they send a ‘we’re working on a solution’. I still didn’t buy this one and just though that sooner or later my little poor suggestion was going to die with the common “we will consider this for vNext”. Three weeks later –on 7/22/04– , when I’ve already completely forgot about this, a “Resolved as Fixed” was submitted. Yes, as I said before “it may take a little while” to get a final response, in this particular case it was “only” 56 days, but it was definitively worth the wait! (in case you haven’t noticed already, yes I’m happy!).

So, if you are not already registered in LadyBug, don’t wait any longer, register now and make yourself heard!!

And when you’re coding in ASP.NET 2.0 and store an Unit type into viewstate, remember… you’re saving 31 bytes thanks to me :-P

Short MVP Links & More

Note: this entry has moved.

Microsoft is boosting MVPs visibility by launching an MVP Community site. This is cool. What is not so cool is the fact that if you’re an MVP and want to include a link to your bio on that site, for example as a signature for newsgroups posts, mailing lists, ect. you have to add around 200 extra chars because the URL produced by that site is huge; this is mine using the MS site URL:

http://www.microsoft.com/communities/mvp/mvpdetails.mspx?Params=~CMTYDataSvcParams^~arg+Name=%22guid%22+Value=%22c451d24e-5397-405f-a0d4-ae797459ccd4%22/^~sParams^~/sParams^~/CMTYDataSvcParams^

Hopefully kzu has noticed this and quickly hacked up a handler to offer shorter URLs; mine now looks like this:

http://aspnet2.com/mvp.ashx?vga

That’s about 180 chars shorter, now imagine the traffic the MVP Community site surely gets each day and try to count the saved bytes for each MVP profile link listed if they were using this format. Yes, @ ClariuS we take performance that seriously! :-)

I can see that Paul noticed this already.

Now, the “More” part of this post’s title

Dave Massy is working in the IE Team for almost a month now and already believes that he wouldn’t feel comfortable using any other browser. W-o-w. Dave, are you serious? Maybe you need to do some catching up of IE current status by downloading the latest bits and playing with them. I bet you won’t resist more than a day or two and will hurry up to download FireFox or any other updated browser.

NikhilKo is back to blogging!! His latest posts contain nothing but excellent inside stuff on the Whidbey bits. Go read them! :-) Now if we could just get ScottGu to start blogging again…

To All MS Employees: How To Destroy Your Credibility in One Second, Guaranteed

Note: this entry has moved.

During last week I had a couple of different meetings (online and in person) with a bunch of Microsoft employees and we touched a big range of topics. One thing I’ve told them all is that if they were willing to destroy their credibility in a snap all they have to do is to try to defend the obsolete Internet Explorer or the non-working GDN Worskpaces. Any of these two positions will have the same instant effect: zero credibility for you.

Two Thumbs Down for HtmlHead

Note: this entry has moved.

As you may already know ASP.NET 2.0 will include a new control, HtmlHead, to serve all your <head> handling needs thus making all previous v1.x hacks unnecessary by providing programmatic access to that tag. So far so good. Let’s hear the bad now.

First thumb down: I received a response in LadyBug stating that viewstate support will not be added to HtmlHead. This was after I chimed about it. Sadly, they didn’t include an explanation backing up their decision (not that they have to but it would have been nice). While I agree that the most common scenario may not require viewstate handling there may be cases where it could be useful, so why not adding support for it and just set EnableViewState to false if you don’t want it?; with this approach you’re giving developers a choice at least…

Second thumb down: HtmlHead handling of meta tags is incomplete, or better said, *very* incomplete. Its RenderControl method is hardcoded to output only name and content attributes. What about support for other valid attributes like http-equiv and scheme? It’s just not there. Please, please… make this control more ‘standard-aware’, look at section 7.4.4 of the HTML401 spec and add support for it. It should be a piece of cake. I’ve filled a new bug in LadyBug (#FDBK11439), let’s see how this one turns up.

Considering the bits are in beta 1 now and that there are –for sure- more important bugs/issues/whatever to be fixed, my guess is that this poor little control will not get much more attention and will hit gold in its current status…