Since my monologue on the IWSDAttachment object last week, it’s occured to me that there’s a much simpler way to explain which programming patterns you have to use when reading from or writing to WSDAPI attachments.
Here’s a table that describes it. To use this table, you need to determine whether you’re writing a client application or a service application, and you need to determine whether you’re writing to an attachment, or reading from it. Then, look up the appropriate row in the table below, and you’ll know which programming patterns you can use. The patterns are described below.
- The basic pattern means you can read your attachment from the same thread as where your messaging occurs. This only works if you’re inside a service method; you can read attachments without another thread.
- The thread pattern is where you spin off another thread to read or write your attachment. I described this in option 2 of the “How do I fix this?” section of the original attachment article.
- The async pattern is where you call asynchronous versions of the proxy method in question (e.g., BeginGetWebcamImage()). I described this in option 1 of the aforementioned section and article. You’ll note that the async pattern isn’t available if you’re writing a service, since WSDAPI doesn’t have a notion of async service calls.
* Important note: the async pattern in the client: read scenario requires that you follow the 7-step instructions at the very end of the original attachment article, or else you risk crashing your application.
And for those of you wondering how I picked the ordering of the rows: it’s the order in which a request/response pattern is seen by the client and service in a typical operation.