Content-Type: text/enriched
Text-Width: 70

	   <underline>Embedded codes passed between GNU talk processes</underline>
        $Id: EMBEDDED.TXT,v 1.5 1999/11/28 22:36:45 zappo Exp $


An embedded code for GNU talk is text passed on the same TCP stream as
typed text, which is prefixed by a special character.  The special
character used is \03, or C-c.  This is because every talk program I
have ever used, and will ever write, uses C-c as a termination
character, thus preventing its ever being passed over a TCP socket via
a talk program because of user input.  Thus, an embedded code consists of:

\03 <bold><<Code Type> <<Embedded Data></bold> \n

Where a code type describes what the message data is, and the embedded
data is the information which will be used to describe some
information.  If the <bold><<Code Type></bold> is not known, the data will default
as a minibuffer message so the user can see what may have gone wrong.

Coded messages are passed between two talk clients via TCP, and also
between the talk client, and the controlling display process when
using emacs.


<underline>Codes used between the talk client and emacs are</underline>:

<bold>00</bold>	Unused
<bold>01</bold>	emacs connect: <<socket port number in host order>
	The connect socket Emacs will connect to via tcp.
<bold>02</bold>	remote connect: <<socket port number in host order>
	the connect socket remote clients connect to.
<bold>03</bold>	new user id: <<user id>
	After emacs connects, this message is sent
	declaring what unique internal user id is associated with that
	TCP connection.
<bold>04</bold>	deleted: <<user id>
	The passed user id has been disconnected for some reason.
<bold>05</bold>	unlogged message: <<message text>
	Do not log this message in *ETALK LOG*, but put it in Minibuffer
<bold>06</bold>      <italic>*OBSOLETE*</italic>

        reply data: <<FAIL || username@host>
	Your recent "Reply" returned this data.
<bold>07</bold>	<italic>*OBSOLETE*</italic>

	Ringer Report: <<username>
	The user listed has sent you an Announce message.  A reply may
	be called for.
<bold>08</bold>	Look here: <<user id> <<hostname>
	The specified user id is found at hostname, not the one
	specified when entering new talk data.
<bold>09</bold>	new user: <<user id> <<username@host>
	The specified user structure has been created due to an unsolicited

        new connection.  Emacs must create a new window for it.
<bold>0A</bold>	new data connection for games
	A new data connection has been established for transferring
        arbitrary data. Param1 is the user-id of the individual who
	requested the connection, and param2 is the function they want
	to share.

<bold>0B</bold>      Show file: <<file name>

        The file specified has just been sent to you.  Display it in a
        buffer as etalk does not have a program association for it.

<bold>0C</bold>      Ask y/n question: <<query>
        Asks a y/n question which requires a response.  The response
        is sent to the TTY of of etalk as just "y<<CR>" or "n<<CR>".
        Etalk puts all other inputs on hold until this response is
        accepted.

<bold>0D</bold>      <<out 1 | in 2><<UID>:TYPE
        outbound or inbound filter for user UID of TYPE has been enabled.

        Type "None" means no filtering.  Anything else is possible for the
        type.  This data is supplied for status display


<underline>Codes used between Etalk clients:</underline>


Many of the following codes may be invalidated with the advent of
DATALINKS.


<underline>Code	Data Description</underline>
<bold>00</bold>	Unused
<bold>01</bold>      <italic>*OBSOLETE*</italic>

        multi-link port number used for transferring port numbers for
	generating new connections.
	<<codes go here>
<bold>02</bold>	String returned from an asynchronous query
	<<y | n><<No message reason>
<bold>03</bold>	Personal name transferral
	<<personal name>
<bold>04</bold>	Y/N asynchronous question from remote
	<<game to play>
<bold>05</bold>      <italic>*OBSOLETE*</italic>

        Request for a list of usernames
	<<no text>
<bold>06</bold>	Request connection to someone you are talking to
	<<username@hostname> <<port number>
<bold>07</bold>      <italic>*OBSOLETE*</italic>

        Beginning of separated text for an extra buffer
	<<name of buffer>
<bold>08</bold>	Startup etalk version transfer
	<<username> <<my connect port> <<TALKPROGRAM> <<Major>.<<Minor><<DELLINE>

<bold>09</bold>      Filter init
	<<filter type> SPACE <<filter data (optional)>


Many of these codes developed under the ETALK emacs interface, which
managed all these codes itself.  I am hoping to revise these codes to
make more sense sometime in the near future.


<underline>Datalink initialization sequence:</underline>


When a new data link is created (without the aid of the talk daemon
protocol) the following codes are read.  After the first three
characters are read, these lists only refer to a datalink, not a
client link.


1) First three characters:

   <bold>"\0\0\0"</bold>  -- new datalink initialized

   <bold>editchars</bold> -- new talk client connection


2) Connection type string: <<user validation:12> <<type> <<parameters> \n

   User Validation: User name of person creating a connection, padded with
                    with NULLS.  (Length is same as in talk msg packets)

   <underline>Type</underline>:
   <bold>\01</bold> - data : Some datatype to be displayed in a window, or other application

   <bold>\02</bold> - auxiliary : etalk-mode -> extra connection for interactive purposes

   <bold>\03</bold> - application : fork() same application on both sides with
                       a socket in some file descriptor, and optional
                       pipe to stdin/stdout.


3.1) Data link codes: <<data-name> \n

   <bold>data-name</bold>: This is a name given to the file where this data will be
              stored.  If the name matches a specific suffix (.jpg, .ps) 
              then a known application is started to view, manipulate,
              or otherwise play with this data.


3.2) Auxiliary codes: <<parameters> \n

   <bold>parameters:</bold> the function to run by the parent process

3.2.1) Paramters to etalk special functions: <<undefined> <<function-name>

   undefined: I'm not sure what to put here yet

   function-name: defines what function is to be played.


3.3) Application codes: <<app-code> <<proxy> <<application> \n

   <bold>app-code</bold>: <bold>\00</bold> - no interface required

             <bold>\01</bold> - keyboard traps required (pipe to stdin/out)

             <bold>\02</bold> - tty required

             <bold>\03</bold> - X windows required

   <bold>proxy</bold>:    <bold>\00</bold> - no proxy
             <bold>\01</bold> - proxy to one other

             <bold>\02</bold> - proxy to N others

   <bold>application</bold>: string which is forked()


<underline>Responses to a datalink:</underline>


After codes are transfered, the ability to accomplish handle the
request is evaluated, at which time the following code is transferred.


<bold>\01</bold>               - Will comply

<bold>\02</bold> << reason > \n - Cannot comply, with << reason >






