Kermit FAQ - Is There a Kermit Library?

(Home) (Prev) (Next)

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:

and on and on. And they desire this functionality to be packaged as a link library for this or that platform, a DLL, an OCX, a VBX, an OLE or OLE-2 object, an Active X control, a Delphi component, a Netscape Plugin, a Java object, a Perl, Tcl, or Python extension, etc etc etc. The combinations of functionality and interface are many, and there is no way we can satisfy them without warehouses full of programmers.

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.


Kermit FAQ / Columbia University / kermit@columbia.edu