Version 11 of Tool Protocol Language

Updated 2008-10-28 12:56:13 by suchenwi

TPL - Tool Protocol Language.

CMcC 28Oct08 17:11 AEST

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:

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 or perhaps TDL (Tcl Data Language)

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.

Dynamics of protocol interaction:

There are several styles of protocol interaction:

  • simple request/confirmation - RPC
  • pipelined request/confirmation - HTTP
    • in-order confirmation pipelining
    • out-of-order confirmation
  • multiplexed streams of the above - FCGI

Consideration must be given to each of these styles.


RS 2008-10-28 - One Tcl-based "data language" is the one that tDom produces with the asList method:

 % dom parse "<foo><bar><grill>42</grill><grill>345</grill><qux a='b' /></bar></foo>"
 domDoc01301840
 % [domDoc01301840 documentElement] asList
 foo {} {{bar {} {{grill {} {{#text 42}}} {grill {} {{#text 345}}} {qux {a b} {}}}}}

It may not be the prettiest sight, but can be parsed with Tcl very easily, and allows to represent the same complexity that XML has, with nested structures and attributes.