30 Is There a Kermit Library?

Many software makers ask us for Kermit software in special forms that can be embedded in their applications, to provide file transfer or other communications functions to their customers.

But each software maker wants something different:

• Connection establishment but no data transfer
• Data transfer using pre-existing connection
• Connection establishment and data transfer
• File transfer only without "bells and whistles"
• Scripting but not terminal emulation
• Serial communication but not networking
• Networking but not serial communications
• Binary file transfer but not text
• Greek character-set conversion but not Cyrillic
• Access to shell escapes allowed
• Access to shell escapes forbidden
• A pretty display
• No display at all

Consequently we recommend that software makers who wish to embed Kermit functionality in their products (communications, scripting, file transfer, terminal emulation, character-set translation, etc) license and use the programs we already have available.

The "API" (Application Program Interface) is the command language. It is more fully expressive, precise, comprehensive, and portable than any other API that could be designed (look at all the commands in C-Kermit or MS-DOS Kermit or Kermit 95; each one is there for a reason). As new releases of the Kermit program come out, your product can be easily updated and will benefit from all the new features, fixes, and speedups automatically.

The recommended method of embedding Kermit in another application is via command-line invocation. The Kermit command line can contain a selection of simple commands, and it can also refer to more complex command files or scripts composed by or included with your application. Kermit can be configured to create any kind of log you need, and it can return the status of its operations in various ways that can be used by your application.

When you license Kermit software for embedding in your application, we are happy to work with you to ensure it meets your needs. And if Kermit protocol transfers are important to you, then it should also be important to you to come to the source -- we developed the protocol, we continue to improve it, we believe in it, and we stand behind it.

Following this advice allows each party to concentrate on what they are good at, rather than unnecessarily duplicating efforts and "reinventing the wheel". You concentrate on your application; we'll do the communications. We support our software, you support yours, everybody is happy.