Adding New Transaction Engines to QUALCOMM BREW's IWeb, Page 3
Choosing to Extend IWeb
Although extending IWeb is not difficult, it's not for the faint at heart, either. From a distribution perspective, this can be a private extension if you're the only developer planning on using the protocol, or you can make the extension available to others as a public extension. Extending IWeb is best if:
- Your protocol is a client-server (request-response) protocol
- Your protocol returns a stream of data
- Your data resides in a database as well as on the Web and you want to abstract away from the database representation
- You want to control your application's state machine via a combination of the IHTMLViewer and IWeb
Good examples of this sort of behavior include the Internet protocols FTP, SMTP, SNMP, POP, and IMAP.
Although most developers treat IWeb as simply an engine for loading Web, resource, and file resident content, it's possible to do quite a bit more by creating IWebEng subclasses. If you're looking for a way to generalize IWeb, or need a generic interface for client-server activities, check out the relationship among the IWeb, IWebEng, IWebRequest, and IWebResponse classes.
About the Author
Ray Rischpater is the chief architect at Rocket Mobile, Inc., specializing in the design and development of messaging and information access applications for today's wireless devices. Ray Rischpater is the author of several books on software development, including eBay Application Development and Software Development for the QUALCOMM BREW Platform, both available from Apress, and is an active amateur radio operator. Contact Ray at firstname.lastname@example.org.
Page 3 of 3