Archive for February, 2009

An Outlook Conversation

Gordon  24 Feb, 2009  1 Comment

One of the things that I had to do in Outlook this week was to determine if an outlook MailItem is part of a conversation. 

After much googlework, I discovered  two properties on the Outlook MailItem – ConversationIndex and ConversationTopic.

To determine if an Outlook Item is part of a Conversation, you need to look at the first 22 bytes of the hex string reported for ConversationIndex. If they are the same, then the message is part of the same conversation. 
 

using Microsoft.Office.Interop.Outlook;      
  1.  
  2. public static bool SameConversation(MailItem item1, MailItem item2)
  3.  
  4.       {
  5.        return item1.ConversationIndex.Substring(0, 22) ==
  6.        item2.ConversationIndex.Substring(0, 22);
  7.       }

That’s all well and good, but note that this property is somewhat unreliable. For starters, in versions of outlook prior to 2003, it returned binary data, instead of a hex string (but if you’re working with versions of Outlook prior to 2003, you probably have other problems…) The other reason this property is unreliable is because it is set by the client – Outlook appends a 5 byte timestamp to the ConversationIndex when you reply. Which is cool, as long as you reply through Outlook.

But – our Infovark mail server is hosted by Google, and I occasionally use the gmail web client to reply to mail,  instead of Outlook. For these conversations, when the replies were eventually retrieved into Outlook via IMAP, they ended up with unique conversationindexes, and so I couldn’t identfy them as being part of the same conversation.

In these cases, that’s where the ConversationTopic Property can help give you a clue. The ConversationTopic is the normalized subject of the message, that is, the subject without all the prefix strings (“Re:Re:” etc.) By comparing ConversationTopics, you can usually piece together the conversation, even if the ConversationIndex is not correct.

Using WCF to return HTML

Dean  18 Feb, 2009  1 Comment

I just answered a WCF question on StackOverflow, and decided it was worth cross-posting here as well.

The question was: What is the best / most flexible way to have WCF output XHTML?

Here’s how we do it at Infovark. While I’m not sure that our approach is the best way, it does the job.

Our approach is to use the DataContractSerilizer to generate XML, then apply a Complied XSLT transform and return the result stream, which should now contain XHTML. Here’s a simplified version of our code:

  1.     public Stream GetItemAsHtml(string id) {
  2.         Item obj = GetItem(objectId);
  3.         Stream xml = GetXmlStream(obj);    
  4.         return TransformXmlStream(xml, defaultTransform);
  5.     }        
  6.  
  7.     public static Stream GetXmlStream(IXmlSerializable item) {
  8.         MemoryStream stream = new MemoryStream();
  9.         using (XmlWriter writer = XmlWriter.Create(stream, new XmlWriterSettings { Encoding = Encoding.UTF8 })) {
  10.             if (writer != null) {
  11.                 DataContractSerializer dcs = new DataContractSerializer(item.GetType());
  12.                 dcs.WriteObject(writer, item);
  13.  
  14.                 writer.Flush();
  15.                 writer.Close();
  16.             }
  17.         }
  18.         stream.Seek(0, SeekOrigin.Begin);
  19.         return stream;
  20.     }
  21.  
  22.     public static Stream TransformXmlStream(Stream xml, string xsltFile) {
  23.         XmlReader reader = XmlReader.Create(xml);
  24.  
  25.         XslCompiledTransform trans = new XslCompiledTransform();
  26.         trans.Load(xsltFile);
  27.  
  28.         MemoryStream stream = new MemoryStream();
  29.         using (XmlWriter writer = XmlWriter.Create(stream, trans.OutputSettings)) {
  30.             if (writer != null) {
  31.                 trans.Transform(reader, writer);
  32.  
  33.                 writer.Flush();
  34.                 writer.Close();
  35.             }
  36.         }
  37.         stream.Seek(0, SeekOrigin.Begin);
  38.         return stream;
  39.     }

It works for us, but if you’ve got other, better ideas, please let me know!

Put the “Web” Back in Web Services

Dean  5 Feb, 2009  1 Comment

I know it’s possible to transmit Internet Protocol by carrier pigeon, but I’m not sure I could recommend it to our customers with a straight face. By the same token, I’m continually surprised to hear vendors and consultants insist that Web Services can be done without the web.

Yet I’ve seen that claim repeated all over the Internet. Sure, it’s true in the academic sense. Technically, there’s nothing wrong with “webless” web services, just like IP by avian carrier will eventually get the job done (though latency and packet loss are a challenge). But practically speaking, why would you use anything other than HTTP?

The “webless web services” meme has infected a number of good ideas. The SOAP standard is a case in point. At first, SOAP was a simple XML wrapper around an XML payload. (Remember when the S in SOAP stood for Simple?) Then a variety of industry heavyweights jumped on the bandwagon, and soon SOAP could be used with any protocol.

With, uh, a few changes. Like five or six additional specifications. And schema. Lots of schema. Maybe a diagram would help? No?

Why not use REST instead?

Nicholas Allen recently shared a great presentation on REST and SOA given by Stefan Tilkov at QCon. Stefan makes some great points about how RESTful web service design aligns well with the goals of Service Oriented Architecture (SOA).

Sure, you could use the WS-* stack if you like, but RESTful web architecture is a proven, scalable and truly simple approach, as long as you don’t mind having to use HTTP.

Much of the added plumbing in the WS-* stack is there to help transition older computer-to-computer network communication technologies. It allows applications that depend on CORBA or DCOM to tunnel through firewalls. But unless you’re trying to retrofit a system built before, say, 1998, you can skip all that stuff.

Wasn’t using web protocol the whole point of web services anyway? As Stefan said in his closing comments: “Protocol independence is a bug, not a feature.”

Use a RESTful architecture for new development. Put the web back in web services.

Microformats Introduction

Dean  3 Feb, 2009  No Comment

I’m on record as being skeptical of the semantic web. Or rather, I’m skeptical of much of the marketing hype around the semantic web. That’s not to say that semantic technologies won’t be useful.

I still believe that both Resource Description Framework (RDF) and the Web Ontology Language (OWL) are too complicated to gain widespread adoption. But maybe we don’t need their academic rigor. Microformats offer a way to get some of the benefits of the semantic web using plain ol’ HTML.

What are microformats? How do they work? Emily Lewis wrote a great series of blog posts introducing microformats. You can also go direct to the source, the microformats homepage, at microformats.org.

An example

Here’s an example of our company address in hCard format.

Infovark

Infovark, Inc.

10104 Bushman Dr.

Oakton, VA, 22124
USA

800-833-9796

The address above is marked up in such a way that (some) web browsers can identify it as a street address. But it’s nothing more than ordinary HTML. Here’s what the code looks like:

  1. <div id="infovark_vcard" class="vcard">
  2.  <a class="url fn n" href="http://www.infovark.com">  <span class="given-name">Infovark</span>
  3.   <span class="additional-name"></span>
  4.   <span class="family-name"></span>
  5. </a>
  6.  <div class="org">Infovark</div>
  7.  <a class="email" href="mailto:info@infovark.com">info@infovark.com</a>
  8.  <div class="adr">
  9.   <div class="street-address">10104 Bushman Dr.</div>
  10.   <span class="locality">Oakton</span>,
  11.   <span class="region">VA</span>,
  12.   <span class="postal-code">22124</span>
  13.   <span class="country-name">USA</span>
  14.  </div>
  15.  <div class="tel">800-833-9796</div>
  16. </div>

It’s simple enough that it just might deliver where RDF and OWL fail, becoming part of every web developer’s toolkit.

Get started

You can experiment by creating your own hCards using the hCard creator.

And if you’re using Mozilla Firefox, you can download the Operator add-in to see — and use — microformatted data embedded in ordinary web pages.

Hat tip: Ajaxian for Getting Semantic with Mircoformats