Paul Vick announced a possible change for VB 9.0, this change would give the IIF method the legitimacy it has long deserved. The issue with IIf is that it’s not a short-circuit operator, which can severely limits its usefulness. Take the following example, that will throw an exception if obj is Nothing:

IIf(obj IsNot Nothing, obj.Property1, String.Empty) 

Since IIf() is just a normal method, all parameters will be evaluated, regardless of weather obj is Nothing. This change would make IIf a true part of the language, a true ternary operator, instead of just another method.

IIf is largely avoided due to performance issues, and its limited usefulness for the reason above. Now that IIf may function as a true operator (though still wrapped in the cloak of a method), it will be a truly useful part of the language, one that I’ve long wished for. I’ve always been a fan of IIf, it’ll be nice to be able to use it again, without the overheard and issues that has long went with its use.

Mr. Vick is still soliciting comments on this change, so now is the time to make your opinion known.

Here is a quick read from Jeff Atwood that all developers should read: Assertiveness for Software Developers. Jeff brings up a great point, developers aren't assertive enough; and that ends up biting us later (I know it's bitten me a few times). 

This is well worth reading, and well worth some serious thought for next time your manager hands you an impossible deadline.

The Valleyschwag crew has released their 5th package, a holiday package no less. I ordered mine a few days ago, and it arrived today. While I believe the guys behind Valleyschwag made a real mistake, it’s nice to see that they are still hard at it.

This is a nice package, with goodies from Guba, mingle and WebShots (along with a few others). All in all, a rather nice package.

After reading Simon Willison’s excellent article on the topic I spent a couple hours last night looking at the current OpenID specification, and after a fair bit of thought found the ideas behind OpenID clever, but not what’s needed for the ID of the future.

What’s Right

OpenID has some really good ideas behind it. Here are a few that really stand out in my eyes.

• If you have a LiveJournal account for example, it just works, no extra sign-up, no additional work.
• The ID is easy to remember, a persons blog / home page URL is among the easiest things for a user to remember.
• De-centralized architecture that minimizes the potential for downtime.
• Anyone can operate an Identity Provider.
• Open, well documented protocol, as well as open-source libraries.
• ID may be portable from one Identity Provider to another without changes to the ID.

What’s Wrong

There are a number of issues I see with this system, while there are certain advantages; some of these disadvantages are quite disturbing. Here are the issues that strike me as most concerning (in no real order).

• SSL (HTTPS) is not required for any communications. This is a potential security issues, though not as large as could be due to the nature of the system.
• Requires editing HTML for users that do not use a hosting service that automatically adds the OpenID HTML code to the proper page(s).
• Not all hosting services allow the user to edit HTML directly.
• Does not offer a way to communicate enough information, such as would be used to expedite an e-commerce transaction. (This may be changed in future versions, or with extensions.)
• No trust relationships, only verifies a person controls a URL.
• No certification or audits for Identity Providers to ensure end-user security.
• Excessive bandwidth usage. Each login requires parsing at least one full HTML page to identify the Identity Provider server. If a user has openid.delegate included in their page, there will be another full page download/parse for each.
• HTML pages must be parsed to identify the Identity Provider server, parsing HTML can raise issues when it contains errors (as is quite common). Seeing as there is no standard library to perform the parsing, HTML with errors may work with some implementations but not with others.
• Anyone that gains access to edit the HTML of the identity URL can steal ones identity just by changing/adding an openid.delegate. This is a real risk in some shared hosting environments.

What We Need

The idea behind OpenID, to create a distributed identity system that is easy to use and can be used universally is a great idea, and one that should be pursued. If this goal could be achieved, it would be a project that would truly help to make the world a better place (at least it in that it would save everybody time). I have great respect for the work of all that have contributed to the OpenID project; it is a great idea and certainly has uses.

To be truly useful though, an ID system needs to be easy to use for people of all skill levels, with and without web sites. It should provide an option to control how much information is shared with a web site (such as OpenID does), and should have the option to provide information such as shipping or billing information to minimize entering the same data in so many web sites. All the data should be transferred via SSL to ensure the highest level of security.

Features of The Future ID

• The protocol should be completely open and well documented.
• The protocol should be XML based so as to be lightweight and easily implemented in any language.
• The ID should be easily used with not only web sites, but via desktop applications and other forms of software that require authentication.
• The organization backing the identity system should arrange for an optional certification program for Identity Providers to ensure that certain basic security policies are implemented. The requirements should be defined by the backing organization and the audit carried out by a third-party auditing firm.
• The IDs should be in an easy to remember format that is easy to type and makes translation back to the provider simple.
• Identity Provides should offer a way to verify that a user is who they claim, not just that they control an ID. This would be an option for users that would be quite useful in applications such as e-commerce use. (This would rely on the provider having a trusted signing certificate and following certain identity verification guidelines.)

While some of these features cover far more ground than something like OpenID, this increased scope is needed to ensure that the ID service can be used in all the needed applications. While it is far more complex to add these extra features, the ability to use the resulting ID for almost any purpose makes it well worth it.

I’m not proposing an alternative to OpenID, simply seeking feedback while passing my feedback on OpenID along for those interested.

If you are looking to get started working with WPF, then Tim Sneath has a great guide for where to start: Building a Perfect WPF Developer Workstation.

This guide includes links to all the software you need, sample projects, and even where to go with questions. If you’re new to WPF, or want to take your WPF skills to the next level, this is a great place to start.

I just dropped by to check my Gmail account (which is almost never used, and the address has never been published anywhere), and found quite a surprise. The spam box currently has 7,026 spam messages!

Keeping in mind that spam is deleted after 30 days, that means I’m getting 7,000 spam messages a month to an unknown, unpublished account! All of my other email accounts use two layers of filtering, one at the server, the other in the client. With this much spam going to an almost secret account, I can only image the spam going to my published accounts.

I actively use six separate email accounts, if each gets 7,000 spam messages a month, I’d be spending my entire week without sleeping just going through spam. Spam just seems that much more evil every day.