Windows Home Server, Part 4 – Technology

I recently had the opportunity to discuss Windows Home Server with Charlie Kindel, Microsoft’s General Manager for the Windows Home Server product. We had an email dialogue, followed by a phone conversation. I’ve pulled together four posts based on our dialogue. I hope to fill in a few areas where the publically available information is a little thin. This is the last post of a 4 part series. (Links to Part 1, Part 2, Part 3)


RH: It is interesting that you opted for a Rich Client vs. Web Interface for the admin panel.  How was this decision made?  Was the connector built using the .Net Framework?  What version?  What language (C#, C++, VB.Net?)  Are there any particular technologies that really shined?

CEK: When building a configuration/admin user experience (Ux) for a network node, one has to consider the following:

– How important is “reach”; that is, how important is it that you have broad multi-platform support?  Windows Home Server is designed to improve the experience in households with multiple PCs. And, especially in v1, our solution is very focused on PCs that are running a modern version of Windows. Therefore the requirement for “reach” does not bubble high up on our list of priorities.

– How important is a “great UI”?  Certainly one can easily build “good” UIs in DHTML, but building “great” UIs is hard. It is even harder to build great UIs in Ajax.  We felt it was super important to create a great UI.

– Designing protocols is hard. Assuming one was to build an admin UI with a rich UI framework (e.g. WinForms/Win32) and run it on the client, what would the protocol back to the server look like? For the Ux to be great it has to be bi-directional and performant. The RDP protocol already exists and is very robust.

– Is 3rd party extensibility important? If so, how do you build your extensibility model?

These, factors, and many others led us to implement the Windows Home Server Console as a rich Win32 application (using .NET and WinForms) that runs on the server, but is remoted to the client using the RDP protocol. This allows us to provide a very rich Ux without inventing new Ux remoting protocols, while being able to provide a great 3rd party extensibility story.

RH: Is there any email story other than file-level backup?

CEK: Nope.


Further Discussion:

Charlie and I talked a bit about how Windows Home Server can be extended by developers. They are planning on releasing an API that will let developers plug into “Peter’s” experience (Check out the Channel9 Video for a description of the Peter persona). Basically they want to let people build into the user-friendly interface to solve different problems like home automation, media, etc.


One thought on “Windows Home Server, Part 4 – Technology

  1. <i>Therefore the requirement for “reach” does not bubble high up on our list of priorities.</i>
    Of course not. <a href="">Interoperability</a&gt; is never on Microsoft’s list of priorities. Never mind that Mac sales are way up or that many hobbyists run Linux. There’s no valid reason at all to not use standard protocols (i.e. a web interface). Plenty of servers already do so and have little usability problems.

Comments are closed.