Version 4 of Tool Protocol Language

Updated 2008-10-28 06:08:59 by CMcC

TPL - Tool Protocol Language.

NB: this is not a description of a new language, but an essay on thinking about tcl in a different way.

The world has many protocols for communicating between processes (IPC). Some are binary, some are ASCII. I will call ASCII protocols for IPC protocol languages.

Examples of protocol languages and binary protocols

  • XML is used in XML RPC type IPC.
  • FCGI, SCGI, CGI have aspects of protocol languages, and some of binary protocols.
  • HTTP is used in REpresentational State Transfer, REST
  • JSON is used in AJAX
  • several data representation languages YAML, ...
  • XDR is a binary protocol used in SUN RPC
  • command-line protocol - used to invoke commands from a process, per the unix system() command, e.g.

Tcl (arguably) has many characteristics desirable in a protocol language:

  • minimal syntax
  • readily parseable
  • omnipresence
  • well known and understood
  • flexible
  • expressive
  • command-args form
  • long history of data-as-code and code-as-data
  • long history of use of little languages

The purpose of this page is to argue this assertion, to explore the truth of the foregoing assertion, to explore counterarguments, to deepen understanding of tcl as a protocol language, to explore prerequisites for its use in this role.

It seems to me CMcC that a cut-down tcl syntax, without special meaning attributed to {*}, $ and would serve well in this role. Such a restricted syntax should be called TPL.

Many applications and systems provide a plugin API. Such an API will necessarily have an expression of the form command+args->result, and will therefore be well suited to a TPL representation.

Examples of plugin APIs:

In many cases, wrappers for library APIs have a similar form, command+args->result, and in fact many critcl and other such wrappers translate C APIs into this form.

The advantage and virtue of TPL is that it formalises the useful TCL syntax subset in a way which might be of interest to people outside the TCL community.

A precedent for TPL may be found in JSON. All command+arg->result forms can be represented as tcl-syntax lists, and these are clearly and obviously trivial to interpret in tcl. Providing a C library which translates a meaningful set of C data types into and out of TPL would enable conversion of any plugin API into wire-ready TPL protocol language.

One thing which would be useful in this endeavour is production of a subset of the tcl syntax *dekalog sufficient to completely define TPL as a subset, and perhaps the full tcl syntax could be expressed in terms of TPL.


enter categories here