The miscellaneous ramblings and thoughts of Dan G. Switzer, II

Can you imagine a world where IE6 no longer existed?

Rey Bango and had a little discussion this morning on Twitter about a JScript update Microsoft recently released to fix a native JSON feature in Internet Explorer 8. I made the comment that it's really only a useful, if Microsoft really automatically pushes the update to users (which I meant via Windows Update—which Rey confirmed to me that they are indeed.) Rey and I then had an ongoing dialog via IM about browser updates in general.

For those of you who aren't aware, Google Chrome uses background updating to automatically update the browser when updates are available. The updating happens seamlessly in the background—there's no visual indication that updating, it happens in the background when you're using your PC.

When I first discovered that Chrome does this (shortly after installing the initial beta,) I was really irritated. I was really against the idea of software upgrading itself without my interaction. I don't like my PC doing things without my permission.

However, after using the beta and having it automatically update itself, I realized it worked pretty well for beta software—which is often buggy. Then I really started thinking about the whole idea of background updating. I started thinking about how much easier my job as a web developer would be, if I wasn't always fighting the battle of supporting old browsers (specifically IE6/7.)

Could you imagine if IE had implemented this concept in Internet Explorer back in 1998? We'd no longer have sites full of HTML, JS and CSS hacks targeted specifically at fixing IE6 or IE7 issues. That would certainly make my job easier.

There are certainly issues with background updating. Browsers that have a plug-in/add-on framework certainly risk breaking the browser with automatic updates—which is definitely an issue. In order to do background updating, you've got to make sure that it doesn't change the user's browsing experience. While Google's has enhanced certain features of Chrome, they haven't implemented any drastic changes to the user's experience—which is important.

While in general, I'm not a fan of automatic updates, in my findings the average web user doesn't really care what their browser is doing—as long as it doesn't change how they use their browser. The average user doesn't proactively look to upgrade their PC—that's one reason so many PCs get infected with viruses/trojans/spyware/etc.

I consider my parents to be a pretty good representation of the normal web user and I just can't get them to keep their PCs up-to-date. No matter how many times I tell them to stay up-to-date on Windows Updates, the response I always hear is "I'm afraid I'm going to break my PC!" Too many users get tricked into clicking and installing stuff from the Internet, because it looks like a PC update and they become afraid of updating.

Anyway, the more I think about it, the more I like the idea of browsers (by default) keeping themselves up-to-date automatically. While there will be vocal crowd against the concept, as long as updates aren't making drastic changes to the user's experience, the general user just doesn't care.

There's definite risk in this approach, because vendors have to be very careful that they're not breaking the user's browser or their experience—that will only frustrate users. However, I'm definitely curious to see if Google is successful in with their current strategy of automatically updating Chrome. I really haven't heard a very vocal outcry against it and Chrome's seems to be picking up popularity, so we'll see how it all plays out.

I have definitely become a fan of the idea that maybe some day in the future I won't have to keep implementing various hacks just because web users don't/won't/can't upgrade their browser. I just think how wonderful the web might be if IE6 was no longer around.

Resolving Mylyn "Insufficient permissions" when connecting to Trac/Apache

For the longest time I've been stuck on Mylyn Eclipse Plug-in v3.0.5—which is very old. Every time I attempted to upgrade to a newer version, Mylyn could no longer authenticate against my Trac installation on Apache. It was a frustrating problem, because I really wanted to upgrade to take advantage of a number of enhancements and fixes.

Today I went upgrade another plug-in and figured I'd try the latest version of Mylyn to see if my issue was resolved. Unfortunately, I was still getting the error "Insufficient permissions for selected access type" anytime Mylyn would try to authenticate via the XML-RPC method. What was really strange, is when I tried connecting via the "Web" method, everything worked fine (which was a new behavior.) So, I decided to spend some time in Charles HTTP Proxy to see if I could debug the issue.

I spent some time monitoring the HTTP traffic, but really couldn't find any rhyme or reason why the authentication was failing. So, I decided to investigate my Apache modules to see if there were any updates to the authentication modules I was using.

One aspect of my Apache configuration that is a little different is that I use mod-auth-sspi module because I authenticate against our Active Directory server (see Configuring Windows Authentication with Apache 2.2.x and Subversion.) After much research and playing around with our configuration, I finally discovered the fix for my problem.

There's apparently an issue with the case that Mylyn sends the authentication information in, the trick was to change my Apache configuration and add the line: SSPIUsernameCase lower

Here's what my authentication configuration rules look like in my Apache httpd.conf file:

AuthType SSPI
SSPIAuthoritative On
# set the domain to authorize against
SSPIOfferBasic On      # let non-IE clients authenticate
SSPIOmitDomain On      # keep domain name in userid string
SSPIBasicPreferred Off # basic authentication should have higher priority
SSPIPerRequestAuth On  # required for IE POST operations
SSPIUsernameCase lower

So, if you're having mystery issues with applications authenticating against your Apache server and your using SSPI, you might try implement the SSPIUsernameCase lower directive.

Keeping an eye on things with a cheap wireless IP camera

Many of you may know that the wife and I have our first baby due this Spring. One the things I've been researching since I found out the wife was pregnant has been IP cameras. I really like the idea of being able to check in on the baby at any time to make sure she's ok—without actually walking in and risking waking her up.

I looked at a lot of various wireless cameras, from baby-specific video monitors to IP cameras, but the features that were key for me were:

  • Night vision—this is a must to check in on a sleeping baby
  • Viewable from my iPhone—the wife and I both have iPhones and this makes the perfect remote video monitor
  • Remote pan/tilt
  • Audio monitoring (2-way audio would be a bonus)
  • A way for the Grandparents to view in on the baby

After looking at some baby video monitors (which didn't meet all the above requirements anyway) I realized that they're all over priced and most got pretty poor reviews. I was leaning towards getting an IP camera anyway, so this made the decision easier.

After looking at many different models, I ended up purchasing the Foscam IP Wireless/Wired Camera (Model: FI8908W). I looked at a few Axis cameras, which are great cameras, but really more expensive than I wanted to pay and really way more than I needed. I also seriously considered getting Astak Mole IP Camera—it met all my requirements, but just was a little more than I wanted to spend. Then just last weekend I stumbled across the Foscam camera. It met all my needs and I could get it shipped for around $95.

After playing around with the camera a bit last night, here's my findings:

  • The camera uses MJPEG for streaming video—which doesn't natively support audio. There is an ASF streaming URL you can access (which supposedly includes audio,) but I haven't found the necessary codec to view it with Windows Media Player. Supposedly VLC will play the stream fine, but I don't want to install another app if I don't have to.
  • Terrific night vision—I was really impressed with the quality in a pitch black room.
  • Pretty straight forward setup. While I found it easy/quick to setup, someone without good gadget skills might struggle a bit.
  • Decent integrate web-interface. While it has lots of options, it's not particularly user friendly. Fortunately, you can give out URLs straight to the stream for family members.
  • Multi-user configuration. You can have up to 8 separate user accounts. Users can either be an Administrator, Operator or Visitor. An Operator can do everything but change configuration—including changing the camera pan/tilt. A Visitor can only view the picture.
  • The picture quality is a little washed out, but seems to do well in low lighting. I've heard that replacing the lens can improve the coloring, but I think it's sufficient for monitoring purposes—I don't need exact color matching.

I would definitely say the camera is well worth the $100. I'm still playing around with it, but there's a nice iPhone app called Foscam IP Control for $1.99 that allows you to remote view the camera and alter the pan/tilt (it does lack a full screen mode.) Since I'm still not sure how I'm going to expose the camera to the world, I may end up changing apps but it works well.

If you decide this camera, you must watch out for Foscam clones. Apparently there are a slew of online resellers selling clones of the Foscam (same box, same design) that use a different firmware. Foscam has a list of authorized resellers on their site. I ended up using an eBay reseller named usahitec. I ordered the camera on Saturday for $95.60 (w/free priority shipping) and it got here yesterday (Wednesday.)

If you want more information on the Foscam camera, check out Gadget Victims has several really insight blog entries:

So far this seems like an excellent way to monitor my sleeping baby and give the out-of-town grandparents a way to keep up with the baby too!