Why is it that people like GUIs so much?
One of the reasons is because a good GUI allows people to spend less time memorizing the syntax and language specifics within a program.
If one has no clue what a particular command is,
one can still check out all the menus until something is found.

With a command line,
this type of hunt and peck is more difficult,
but not impossible.
The command line must be command contextual to do this.
A typical operating system interface maintains a file system context and not a command context.
Cisco IOS and other network equipment often use a command contextual interface,
and this is sometimes called Cisco-like.
Network equipment usually has a much simpler file system and Network Administrators are usually forced to manage many more types of devices than System Administrators.
Network Systems also generally require much less daily contact,
so it is important for the user interface to be as helpful as possible,
because the operator has likely forgotten half of the command syntax.

For functional quality assurance testing,
the demands are much more in line with Network Administration.
One will need to plug in a module that tests some sort of capability,
write and run some tests,
and then do something else for a bit while the developers/integrators fix the problems.
Thus TCLI attempts to use the Cisco-like contextual paradigm to provide a user interface to support testers.

A private object method that has all the default commands. The ones we just can't live without. Well, maybe not all the ones we can't live without, but all the ones that have actually be written so far.

Some transports may need to store extra state information related to the control. Rather than force them to maintain some sort of lookup table, the Control object can have attributes generated on the fly. This operates the same as for Request objects and within the transports themselves. It is exected that the Transport documentation will describe what is being stored in the Control.