From our experience, when a software developer creates a protocol-based solution, there are two consistent patterns to their project requirements. The first is that a project is often single-protocol based. This means that all the effort to understand and use a communications technology is based around a single protocol as the project usually requires a specific technology. With that in mind, the time and effort a person will devote to using a protocol is usually substantial as the protocol is often at the core, or at least a crucial aspect of the business solution the application is attempting to bring to the table.
At the early stage of a project, the protocol requirements tend to be very general. For example, the requirements may simply specify that the application needs to create an e-mail message containing some data and send it using SMTP to a specific mail address. That requirement is simple enough. A developer would then go out in search of a component that can easily handle sending an SMTP message. Through the evolution of a project, certain details become more apparent to a developer or the requirements can change to meet changing project circumstances. Now, this simple e-mail message is no longer just some text, but it may need to be dynamically created using graphics that must be extracted from a database and placed inline into the actual message, plus a secondary file that must be attached right before the message is sent. Furthermore, the recipient of this email is using a parser to extract its contents and needs to have the headers formatted in a very specific manner. Now, what was once just a simple requirement has turned into a major research project to understand how emails are constructed so that they can be formatted in a specific way. The requirement has suddenly gone beyond just using an SMTP component to send a message. This situation, referred to at Dart as “Scaling Complexity” is not uncommon, and in fact is the norm with most development projects using protocols. Because most developers lack experience in the protocol-realm and can’t predict all the permutations that evolve through the course of a project, the complexity of a task will increase as more knowledge is gained about both the requirements and how a protocol needs to be manipulated to successfully complete the task.
To alleviate such problems, the Dart philosophy has been to approach every protocol with a “product” mentality rather than just provide broad support across a multitude of protocols in a single package. By creating a correlation between a product and the developer requirements for a particular protocol, a product designed around a protocol (and the subsequent developer requirements) offers substantially more depth than a broad “IP-Pack” approach that just glosses over the basic IP functionality. In fact, our development team will spend more time on a single protocol-based product than other development shops will spend on their whole multi-IP based package.
Returning back to Mail as an example, PowerTCP Mail for ActiveX does not only come with SMTP, POP, and IMAP functionality, but a powerful Message object. This object is actually the focus of the product as all the complexity of electronic mail is in building or reading a message, and not the physical act of sending or receiving. Our goal with the Message object was to attack all the possible complexities a software developer would face in building a mail message and enabling the required functionality in an easy-to-use way. This is accomplished by letting a developer access the different parts of a message in an object oriented manner, including the ability to create recursive messages. Beyond just encoding the message, the Message object will decode a complex message into properties and that includes recreating any attached messages to an infinite level of recursion in subordinate collections. On top of this, Dart also created helper objects that we include in every product to assist developers in managing the data they are attempting to get into and out of our components. These helper objects include the DartStream object that adds stream support so that data can be moved into or out of either memory of files with simplicity, and exposes the data on a string or byte level. Also we created our own DartStrings collection that enables string manipulation with the speed normally associated with C++ level activity, bypassing the performance problems of the native Visual Basic Collection object.
This model of attacking the problem of “scalable complexity” is visible in all of our products and extends beyond just the component architecture. Dart works exhaustively to incorporate maximum protocol compliance, which is especially important in such complex protocols as SNMP. Beyond just compliance, we test against numerous 3rd party clients and servers, knowing that others sometimes deviate from protocols. Dart also closely monitors CERT security advisories because we know that security and reliability are important to our customers.
In the end, we think that the cost of purchasing a single protocol solution will more than pay for itself during the life of a project and provide a substantial savings over the value proposition that “IP-Pack” vendors bring to the table. By eliminating much of the protocol complexity the PowerTCP products can save valuable development hours and eliminate the headaches of ever expanding project requirements.