Adding New Transaction Engines to QUALCOMM BREW's IWeb
Because BREW is a connected platform, most BREW developers have at least seen IWeb, even if they haven't had the opportunity to use it much. Its interface is both simple and appealing: Set some options, call IWEB_GetResponse with a callback, and a little while later, IWeb invokes your callback with a result and any data retrieved is available on an ISource from which you can read. Posting data is easy, too; just include an ISource in the outbound request containing the data you want to send to a remote server, and IWeb reads the data from the source and sends it to the remote server prior to calling your callback with the result.
But what if you need to create a new transaction interface? Perhaps you want a Web-based application to access local and remote data using the same engine, or perhaps you want to develop an application using an Internet protocol such as HTTP or SMTP not supported by BREW. Do you need to create a wholly new interface wrapping or replacing IWeb? Not at all—you can extend IWeb with your protocol, letting clients of your protocol use the same familiar interface provided by IWeb.
Peering Under IWeb's Hood
Even if you don't intend to extend IWeb, it's interesting to understand how IWeb actually works because it provides a good example of how to structure various interrelated components that solve a complex problem in a general way within Qualcomm BREW. Figure 1 shows the relationship among the various interfaces in the IWeb family.
As you can see, it isn't actually the IWeb interface that's responsible for handling URL protocols such as HTTP; in fact, the responsibility is handed off to interfaces implementing the IWebEng interface. The IWeb interface searches the system registry for classes registered with the HTYPE_BROWSE base class and specific protocol schemes (instead of MIME types), selecting the class that matches the indicated scheme. Once found, IWeb creates an instance of the class and invokes its Transaction method to perform the necessary request.
For all this to work, the class created by IWeb must:
- Implement the IWebEng interface.
- In your Transaction method, cache aside the callback pointer, create the resulting IWebResp instance, and start your transaction asynchronously.
- When your transaction is complete, populate the IWebResp instance with the result and invoke the resulting callback.
The devil is in the details: You need to create a new IWebEng subclass for your protocol.