Microsoft SharePoint roadmap absence

Nobody but the Microsoft product team seems to know where the next release of SharePoint Services/Portal Server will be heading. Customers don't, Partners don't, MVPs don't, and even Microsoft's own portal guru's/evangelists such as Mark Harrison don't.

Having had a closer look at the SharePoint externals and internals to find out how to get my way with it after all I finally dived into the web service interfaces and the related CAML (Collaborative Application Markup Language) documentation in the SharePoint SDK. CAML first of all provides a flexible schema definition facility that underpins SharePoint's ability to create/modify tables (lists in SharePoint speak) at run-time and thus works around the limitations of SQL Server (and any other RDBMS that I know of). The second part of CAML seems to focuses on the rendering of list content.

So SharePoint defines a data schemas and flexible data storage mechanism, as well as rendering and searching of the this data. Is it just me, or does there seem a lot of overlap between the core SharePoint infrastructure and the functionality that was originally intended to be delivered by WinFS in Longhorn. Before Microsoft's announcement of WinFS delay, it would make sense for a next version of SharePoint to use WinFS instead of its current data typing and storage mechanisms. If the SharePoint product team was indeed heading that way, they are now faced with some serious questions about how to go forward. That would certainly explain the complete lack of clarity about SharePoint's future direction.

Proxy (Auto-)Configuration Blues

I got seriously fed up with switching proxy settings when switching location of my laptop between company, home and client/partner networks. For some reason or another automatic configuration would not work everywhere, so I decided to write my own PAC (proxy autoconfiguration) script.

The authoritative reference documentation for PAC scripts by Netscape was easily found by googling for "proxy autoconfiguration script" (Interestingly, the same search on MSN did not even return this URL on the first page of search results). A PAC script is nothing more a bit of JavaScript code that must define a FindProxyForURL function.

My initial script looked like this:

function FindProxyForURL(url, host)
{
  if(isInNet(myIpAddress(), "158.234.0.0", "255.255.0.0"))
  {
    // Connected to company intranet
    return "PROXY proxy1.intra.example.org:80; PROXY proxy2.intra.example.org:80
  }
  return "DIRECT";
}

If current IP address of machine is in the company intranet subnet, use the proxies that provide internet access from the intranet (company network scenario), otherwise assume direct access is possible (home network scenario).

Unfortunately this script did not work straight away. Writing it was pretty easy, debugging not. An old MIND article provided some help in this area. Attaching a debugger to Internet Explorer didn't seem to work for me - the auto configuration script block didn't show up in the Running Documents. JavaScript alerts in the PAC file helped highlight the problem however (IE6 shows the alerts in popup windows, Firefox writes the alerts to its JavaScript console). It turned out that the myIpAddress function returned the IP Address of a loopback adapter (installed for more complex VirtualPC networking scenarios) instead of the IP Address of the Ethernet adapter connected to the LAN.

Credits to Oliver Presland (Microsoft UK) for pointing out that this problem could be tackled by changing the priority of the network connections. Something that is much more obscure now (open Network Connections applet from Control Panel, Advanced/Advanced Settings... menu, Adapters & Bindings tab, Connections list) than it was in NT4 days. Once the LAN adapter had top priority, the PAC script worked as intended both in the office and at home. That is, until I set up a VPN connection to the company intranet...

The VPN software creates a temporary network adapter that gets an IP address in the company intranet subnet and always seems to claim top connection priority. The result was that once a VPN connection had been setup, all internet traffic would be routed via the company intranet and its proxies. To prevent unnecessary use of company resources I adjusted the PAC script:

function FindProxyForURL(url, host)
{
  if (isResolvable("myhomepc"))
  {
    // Can resolve DNS queries without proxy
    return "DIRECT";
  }
  else if(isInNet(myIpAddress(), "158.234.0.0", "255.255.0.0"))
  {
    // Connected to company intranet
    return "PROXY proxy1.intra.example.org:80; PROXY proxy2.intra.example.org:80";
  }
  return "DIRECT";
}

This seems to have done the trick. Update: Only problem now is that resolving host names that cannot be found takes an awful long time. Using subnet tests only is a lot faster, so I will do a bit more work to find out which company subnets are used for VPN clients and which are used for company LAN clients.

Good start of the year

It has been an interesting first week. I got a gmail account and became a Microsoft MVP (Visual Developer - Solutions Architect)! I need to further explore the benefits of both, but it's already becoming clear that the latter provides another, pretty powerful route into the Microsoft organisation.