Not much blogging of late. Trend likely to continue. Details at 11.

However, I did make an interesting discovery about Windows SharePoint Services I wanted to share. Obviously, I’ve been thinking WSS in terms of blogging (hence the project to expose RSS from WSS). However, I’ve been frustrated by what should be a simple little thing. WSS includes a rich text editor that enables me to write content that’s bold, italics, colored, fonted, sized, indented, bulleted, etc. However, until today, I couldn’t figure out how to do hyperlinks. WSS will automagically render a url as a hyperlink. But there was no way to build an anchor tag hyperlink, so your forced to embed urls directly in the text. I didn’t like that, so I set about trying to fix it. Turns out to not be a big deal.

It turns out that the SPFieldMultiLine class supports a property named AllowHyperlinks. If you can flip this bit, the rich text editor in WSS will suddenly get a Hyperlink button and enable the creation of anchor tag hyperlinks. Unfortunately, there doesn’t appear to be any way to flip this bit via the existing UI as of B2TR (no, even though I work at MSFT, I don’t have the RTM bits yet). So I built a web app (as per these instructions) that programmatically flipped that bit via the WSS object model. I also could have done it via a console or windows form app, again via the WSS object model. However, that object model only works on the WSS machine itself – there’s no concept of remoting via the OM. But WSS does expose much of its functionality remotely via web services, including a List web service.

The WSS Web Service interface (WSI?) is a little funky, but I munged up a little utility to flip the AllowHyperlinks property programmatically. The inputs and outputs of the service are XML (actually an XML grammar called CAML) so the inputs and outputs of the service proxy are XmlNodes. The DOM is an ugly way to build XML documents, so I used Chris Lovett’s XmlNodeWriter utility class to get an XmlWriter interface on my XmlDocument. Other than that, the code was pretty straight forward. In pseudo-code, it looks like:

1. Call ListServiceProxy.GetList(listName) to get the definition of the list in CAML
2. Use XPath to find the element that represents the field I want to change (//sp:Field[@DisplayName='fieldName'])
3. Create a new XmlDocument that contains a single method block for the field I want to change (see docs for UpdateList for explanation). Write the CAML representation of the field into the method block. This CAML is identical to the CAML from the previous step, except that I’ve added AllowHyperlinks=”TRUE’
4. Call ListServiceProxy.UpdateList, passing in the the constructed XmlDocument as the updateFields parameter.
5. UpdateList returns an XmlNode that contains the result of the update. XPath query via method block ID to determine if the update succeeded or failed.

I will post the code after I clean it up a bit. However, I don’t know when that will be.

Ok, so you have this cool sounding technology called SPOT. People are impressed that you, Microsoft, have come up with a cool way to send information to your watch. So what do you do? Hide the technology under a crappy name like MSN Direct. So does that mean I have to have MSN? What if I already have AOL? Every part of Microsoft that I have come into contact with has impressed me, except for marketing… marketing causes Microsoft more headaches that any other department. (Just think about .NET) [.Avery Blog]

As someone who has spent most of the past three years explaining .NET to customers, I’ve given up on the marketing department. I tell customers point blank: “Microsoft is the company with the great technology and bad names”.

MSN Direct and .NET aren’t even the worst cases of this:

• Argue/flame if you like, but MTS was the first of the modern application servers. (The original version of EJB was essentially a clone of MTS.) But did we make a big deal about it? No, we shipped it as an “additional technology” included in the NT 4 Option Pack. As if it was optional.
• Windows 2000? Is that the new version of Windows 98? 😦
• MTS at least stood for something. What the heck does COM+ stand for?

Brad Abrams blogged on the importance of measuring performance before making design changes. “Have you measured it?” is a question I ask customers all the time. Recently, I was meeting with an ISV that had been directed to me regarding improving the performance of their .NET app. They were using .NET Remoting between their web and app tiers. They were using the HTTP channel with the binary data formatter and felt that if they moved to the TCP channel they would improve their performance dramatically. However, making this switch would entail writing a non-trivial amount of “plumbing”. They would need their own service to host the objects instead of just using IIS. They would also need to build custom code to support encryption and authentication on the TCP channel (I know there is democode for doing this floating about – but as an ISV, they would need to support the code as if they had written it which is still non-trival).

It turns out they had not, in fact, measured the impact. And in digging deeper in their architecture, it turned out that they were making multiple calls between their web front end and application tier on each web page request, with the average being about five. While TCP is in fact faster than HTTP, it’s not going to provide the same level of improvement that collapsing those five remote calls into one would be. I explained to them the Remote Facade and Data Transfer Object patterns as a way to dramatically improve the performance of their application while avoiding the need to build/maintain a bunch of plumbing. They liked it and as far as I know, they decided to head in that direction. I’m waiting to hear exactly how much of a performance gain they get.

If you don’t measure, you don’t know where the bottle necks are and you don’t know where to get the greatest impact for the least amount of effort.

You can read the help files, now you can hit the ground running when you build WebParts with templates for VS.NET. This has been released before, this one is for the RTM version of SharePoint. Of course, one of the System Requirements for building a web part assembly is “Access to the Microsoft Windows SharePoint Services assembly”, which still hasn’t shipped yet. So no rush on downloading this one.

And speaking of SDKs, you can view the docs for v1.2 of the RTC Client API and download the SDK. This is an upgrade to the v1.0 of the RTC Client API that ships with WinXP. It’s been upgraded to support Live Communication Server (previously known as RTC Server). Unlike the P2P SDK, the RTC SDK is COM based, which should be easier to wrap in managed code