1. Introducing the ToolTalk Service
2. An Overview of the ToolTalk Service
4. Setting Up and Maintaining the ToolTalk Processes
5. Maintaining Application Information
6. Maintaining Files and Objects Referenced in ToolTalk Messages
7. Participating in ToolTalk Sessions
13. Managing Information Storage
A. Migrating from the Classing Engine to the ToolTalk Types Database
B. A Simple Demonstration of How the ToolTalk Service Works
C. The ToolTalk Standard Message Sets
What files are part of the ToolTalk service?
Where is the initial X-based ttsession started?
Where is rpc.ttdbserverd started?
Where are the ToolTalk type databases stored?
Do I need X Windows to use the ToolTalk service?
Can I use the ToolTalk service with MIT X?
Where is the session id of the X-session?
How does tt_open connect to a ttsession?
After calling tt_open, when does a session actually begin?
If another session is attached, does the first session get killed?
How can processes on different machines communicate using the ToolTalk service?
Connecting to the Same Session
What is the purpose of tt_default_session_set?
How can a process connect to more than one session?
Can you start a ttsession with a known session id?
What information does a session id contain?
Is there a standard way to announce that a new program has joined a session?
What is the basic flow of a message?
What happens when a message arrives to my application?
How can I differentiate between messages?
Can a process send a request to itself?
Can I pass my own data to a function registered by tt_message_callback_add?
How can I send arbitrary data in a message?
Can I transfer files with the ToolTalk service?
How are memory (byte) ordering issues handled by the ToolTalk service?
What happens when I destroy a message?
Can I have more than one handler per message?
Can I run more than one handler of a given ptype?
What value is disposition in a message?
What are the message status elements?
What does the ptype represent?
Why are my new types not recognized?
Is ptype information used if a process of that ptype already exists?
What does tt_ptype_declare do?
Must I register patterns to get replies?
How do I match to attribute values in static patterns?
Why am I unable to wildcard a pattern for TT_HANDLER?
Can I set a pattern to watch for any file scoped message?
Is file scope in static patterns the same as file_in_session scope?
What is the difference between arg_add, barg_add, and iarg_add?
What is the type or vtype in a message argument?
How does ttsession check for matches?
How many kinds of scope does the ToolTalk service have?
What should the tt_db databases contain?
Do ttsession and rpc.ttdbserverd ever communicate?
What message bandwidth can be supported?
Is there a limit to the message size or the number of arguments?
What is the most time efficient method to send a message?
What network overhead is involved?
Does the ToolTalk service use load balancing to handle requests?
What resources are required by a ToolTalk application?
What happens if the ttsession exits unexpectedly?
What happens if rpc.ttdbserverd exits unexpectedly?
What happens if a host or a link is down?
Is message delivery guaranteed on a network?
Is there a temporal sequence of message delivery?
Can my applications hide messages from each other?
Is there protection against interception or imitation?
Where are queued messages stored and how secure is the storage?
Is the ToolTalk service C2 qualified?
How can I trace my message's progress?
How can I isolate my debugging tool from all the other tools using the ToolTalk service?
Can I use the ToolTalk service with C++?
Should I qualify my filenames?
Can you tell me about ToolTalk objects?