Big news on the Mac e-mail front.
First, Microsoft has released the Exchange Web Services (EWS) edition of Entourage, which you may remember from back in January. If you’ve been using the beta version, you will almost certainly be pleased with the vast improvements in sync speed since the beta. MS has also fixed a number of annoying sync bugs. Remember, the EWS version requires that you have Exchange 2007 SP1 with update rollup (UR) UR4 or later.
Next, MS announced today that the next version of Mac Office will contain… not Entourage but Outlook for the Mac. They have not yet announced the exact details of what “Outlook” means in the Mac context (except to say that it includes support for AD RMS), but the
Entourage Outlook for Mac team is well aware of the major features that Outlook for WIndows has, and based on my discussions with them I am pretty optimistic about what we’ll see in the next version.
I’ve recently been spending time programming again. This has been a welcome return to my roots, and it’s certainly reminded me of the pleasure that comes from building good code. Of course, every pleasure has its obverse, and I was reminded of that today because I spent all day beating my head against what appeared to be a bug in NSXMLNode. You’re supposed to be able to use the nodesForXPath: method to do an XPath query against an XML tree. I’d written some code that sent an Autodiscover request to Exchange and parsed the returned data (which looks like this), but my code never found any EwsUrl nodes, even though they were plainly visible.
I tried the xpath command-line tool, and it did what I expected; “xpath ~/Desktop/EWS.xml //EwsUrl” returned both nodes. Apple’s own XMLBrowser sample (in /Developer/Examples/Foundation/XMLBrowser) didn’t work properly either, but the XMLMate plug-in for TextMate did. I looked carefully at the Autodiscover sample in the Exchange 2007 SP1 SDK and found that everything looked OK. Then I went back to my main reference for this stuff. On page 780, I finally found the answer in a subtle clue: the book’s sample was using an XPath query that included the namespace! I modified my code to look like this:
NSXMLNode *rSpace = [NSXMLNode namespaceWithName: @"r"
[[adResponse rootElement] addNamespace:rSpace];
NSArray *idList = [responseRoot nodesForXPath:@"//r:EwsUrl" error:&err];
That solved the problem. So, lesson learned: always make sure that you’ve registered the correct namespace when using nodesForXPath!
Geez, I never would have figured this out on my own. Xcode has its strengths, but it’s certainly a much different beast than Visual Studio, which I still prefer. Anyway, if you want to rename an Xcode project, you can’t just change the project name in the Finder; you have to modify a bunch of the project metadata too. See these steps for complete details.
I’m working on a demo application that uses Exchange Web Services from Cocoa, Apple’s object-oriented OS framework. Cocoa is a really interesting environment, with a lot of very cool capabilities. One thing it can’t do, though, is give your application a way to examine a returned certificate that the framework thinks is bad. The certificate might appear to be bad because it’s expired or invalid, or merely because it’s self-signed (or issued by another untrusted CA). Because many Exchange servers will have self-signed certificates, the demo app won’t work on them without a way to finesse this problem. Because it’s just a demo application, I didn’t want to require the user to add the self-signed certificate to their certificate trust list, and I didn’t want to turn off certificate checking completely (if that’s even possible).
The answer, which I found here, is to override a private, unsupported, category method, allowsAnyHTTPSCertificateForHost. Just call it with the FQDN of the host whose certificate errors you want to ignore and you’re golden.