Daniel Moth sent me a note telling me that he would be at MEDC (great news), and that he was looking forward to my "talk". I want to set expectations here. I'm on a panel. I'm taking my cue from Jonny Moseley on Warren Miller's Fifty, when he introduces a freestyle event: "This is how we get it done these days. It's much too dangerous for me to actually be out there".
A panel is what you sign up for when you are too tired [ frightened | unprepared ] to do a talk, but you want to get a cool shirt. I'm actually honored to be on a panel. It seems only yesterday I was skipping school and firing home made potato(e) guns from inside an abandoned railway car, and now I'm on a panel. Cool.
The only reason I have time to write this is because folks I work with are sweating it out right now, reviewing their slides, practicing in front of mirrors, taking conflicting advice from lots of people on the manner of their speech, posture, dress, font size, etc etc. My job is to wander into their offices, and give them advice on the manner of their speech, posture, dress and font size. It's a good job.
Be sure and check out the talks by Richard Greenberg, Roman Batoukov, Scott Holden, David Kline and Mark Ihimoyan from my team.
I'm excited about MEDC. You have made the .NET Compact Framework a pretty hot topic. Seth Demsey and Neil Enns will be on stage with Bill at the keynote and they're going to show off some cool stuff.
I've been involved in some preparation for the panel. The general theme is around helping explain what tool is best for what job. Frankly, I'd prefer if the panel format was such that I just asked you questions on this topic. We've effectively built a toolkit with the .NET Compact Framework, with an almost dizzying numbers of choices. I'll defend this, given that there are lots of different programming problems, solutions, and even skills sets, conceptual models and biases about the best way to solve a given problem.
That said, I'm struggling to think about how I would position the following technologies, all of which we support today:
I look forward to talking to folks at MEDC to learn what works in the real world (i.e. outside Redmond - I've seen it on several vacation trips).
It never hurts to get noticed by the boss.
I had mentioned in a previous post that we were thinking about the problem of transiently connected networks for our next release. We're still thinking about it, most recently about the importance of addresses.
People focused on networking technology (like me) tend to under-appreciate the importance of addresses to customer adoption of a solution. Addresses are the proxies that people use to identify other people or organizations. Key qualities of great address, for a large network, are discoverability, lifespan and administration. Phone numbers are examples of addresses that are highly discoverable, stable for a long length of time and formally administered by an organization. Instant messaging addresses are slightly less discoverable, stable enough and created ad-hoc with formalized collision detection. URLs and email addresses are the two other very successful addresses, both with distributed administration and collision avoidance schemes.
The other critical quality of an address is the number of addressable endpoints. Phone numbers are excellent in this regard. Any one of over 1 billion landline and 1 billion wireless phones can address any other phone, simply by knowing a phone number. Those of us from the PC networking and Internet world often marvel at the continued success of SMS text messages, given their very high cost, limited bandwidth and boring user experience. Yet no other technology offers a set of addresses, and associated underlying protocols, with the qualities that customers value.
It sometimes comes as surprise that phone numbers could be superior to any one of several addresses used on the Internet. Despite the technical elegance of the basic TCP/IP machine address / application address, IP addresses are nearly useless to customers. While the shortage of V4 addresses has received considerable attention, the impact that the various techniques to work around this problem (DHCP, PPP, NAT) have had on the inherent peer to peer nature of the TCP/IP is underappreciated. The modern internet consists of a relatively small number of machines that have fixed addresses and a much larger number of machines that have very short lived addresses that are reused from a pool. The IP address of the latter group of machines is effectively useless as an endpoint address, doing little more than satisfying the technical need for a legal local address in a purely “connect out” environment.
Various dynamic name server technologies, like DNS and WINS can hide transient addresses behind a name with a longer lifespan. This is not likely to ever be practical on an Internet scale, but works fine for isolated networks within organizations. The effect of this is to create many new address spaces, with similar looking addresses but no interoperation among them.
URLs, since they build of DNS names, suffer from the same disadvantages. The URL space is extremely large and flexible, but it is difficult or impossible for me to offer you a URL that you can reliably address on my corporate machine, home or PocketPC.
IPV6 may eventually solve this, by assigning everyone an address with the qualities of a phone number. Dynamic DNS servers and/or distributed name resolution algorithms will make these addresses friendlier to humans. Unfortunately, the rollout of IPV6 to internet or phone system scale is a many year exercise, and even when the IP address space is suitability discoverable and long lived corporate security concerns almost guarantee that true peer-to-peer connectivity between any two machines in the world will never happen.
There is set of business and technical issues around mobile devices and operators that also impede true TCP/IP level peer connectivity. It is reasonable to plan for the vast majority of devices to be connect out only at the lower layers. A peer to peer user experience will almost certainly have to be created by using “relay servers”, like mail and instant messaging do today.
Anyway, the main thing this thought exercise has reinforced for me is that I have to hire some people, smarter, and harder working than me, so I can slack off and shoot potato guns. If you're interested, contact me at firstname.lastname@example.org. We're also look for hotshot graphics engineers too. If no one applies, you'll just have to use whatever stuff I can think up.
I was late for work this morning. After my family left in the morning, and then my immediate neighbors left, I cranked the volume up to 11 and watched Mike Oldfield's Art in Heaven DVD. If you like Mike Oldfield, or progressive rock, this is a great disk. The concert was New Year's Eve in Berlin, and it makes me sad that I was huddled in the basement retesting the generator and checking the fresh water supply. But before you take musical advice from me, consider that I can lay down Pink Floyd, Pet Shop Boys, Al Stewart, B-52s, Neil Diamond and The Irish Rovers on the same tape (electro-mechanical playlist like thing) and think it sounds pretty good.
See you in Las Vegas.
This posting is provided "AS IS" with no warranties, and confers no rights.