Chnaged "disconnect" client operation to deliver the reason
[silc.git] / lib / silcclient / client_ops_example.c
1 /* Predefined stub functions for the SilcClientOperation callbacks.
2    You can freely use this template in your application. These are
3    the functions that you as an application programmer need to implement
4    for the library.  The library may call these functions at any time.
5
6    At the end of this file SilcClientOperation structure is defined, and
7    it is the one the you will give as an argument to the silc_client_alloc
8    function. See also lib/silcclient/README file, and silcclient.h. */
9
10
11 /* Message sent to the application by library. `conn' associates the
12    message to a specific connection.  `conn', however, may be NULL.
13    The `type' indicates the type of the message sent by the library.
14    The applicationi can for example filter the message according the
15    type. */
16
17 static void
18 silc_say(SilcClient client, SilcClientConnection conn,
19          SilcClientMessageType type, char *msg, ...)
20 {
21
22 }
23
24
25 /* Message for a channel. The `sender' is the sender of the message
26    The `channel' is the channel. The `msg' is the message.  Note that
27    `msg' maybe NULL. */
28
29 static void
30 silc_channel_message(SilcClient client, SilcClientConnection conn,
31                      SilcClientEntry sender, SilcChannelEntry channel,
32                      SilcMessageFlags flags, const unsigned char *message,
33                      SilcUInt32 message_len)
34 {
35
36 }
37
38
39 /* Private message to the client. The `sender' is the sender of the
40    message. */
41
42 static void
43 silc_private_message(SilcClient client, SilcClientConnection conn,
44                      SilcClientEntry sender, SilcMessageFlags flags,
45                      const unsigned char *message,
46                      SilcUInt32 message_len)
47 {
48
49 }
50
51
52 /* Notify message to the client. The notify arguments are sent in the
53    same order as servers sends them. The arguments are same as received
54    from the server except for ID's.  If ID is received application receives
55    the corresponding entry to the ID. For example, if Client ID is received
56    application receives SilcClientEntry.  Also, if the notify type is
57    for channel the channel entry is sent to application (even if server
58    does not send it because client library gets the channel entry from
59    the Channel ID in the packet's header). */
60
61 static void
62 silc_notify(SilcClient client, SilcClientConnection conn,
63             SilcNotifyType type, ...)
64 {
65
66 }
67
68
69 /* Command handler. This function is called always in the command function.
70    If error occurs it will be called as well. `conn' is the associated
71    client connection. `cmd_context' is the command context that was
72    originally sent to the command. `success' is FALSE if error occurred
73    during command. `command' is the command being processed. It must be
74    noted that this is not reply from server. This is merely called just
75    after application has called the command. Just to tell application
76    that the command really was processed. */
77
78 static void
79 silc_command(SilcClient client, SilcClientConnection conn,
80              SilcClientCommandContext cmd_context, bool success,
81              SilcCommand command, SilcStatus status)
82 {
83
84 }
85
86
87 /* Command reply handler. This function is called always in the command reply
88    function. If error occurs it will be called as well. Normal scenario
89    is that it will be called after the received command data has been parsed
90    and processed. The function is used to pass the received command data to
91    the application.
92
93    `conn' is the associated client connection. `cmd_payload' is the command
94    payload data received from server and it can be ignored. It is provided
95    if the application would like to re-parse the received command data,
96    however, it must be noted that the data is parsed already by the library
97    thus the payload can be ignored. `success' is FALSE if error occurred.
98    In this case arguments are not sent to the application. The `status' is
99    the command reply status server returned. The `command' is the command
100    reply being processed. The function has variable argument list and each
101    command defines the number and type of arguments it passes to the
102    application (on error they are not sent). */
103
104 static void
105 silc_command_reply(SilcClient client, SilcClientConnection conn,
106                    SilcCommandPayload cmd_payload, bool success,
107                    SilcCommand command, SilcStatus status, ...)
108 {
109
110 }
111
112
113 /* Called to indicate that connection was either successfully established
114    or connecting failed.  This is also the first time application receives
115    the SilcClientConnection objecet which it should save somewhere.
116    If the `success' is FALSE the application must always call the function
117    silc_client_close_connection. */
118
119 static void
120 silc_connect(SilcClient client, SilcClientConnection conn,
121              SilcClientConnectionStatus status)
122 {
123
124 }
125
126
127 /* Called to indicate that connection was disconnected to the server.
128    The `status' may tell the reason of the disconnection, and if the
129    `message' is non-NULL it may include the disconnection message
130    received from server. */
131
132 static void
133 silc_disconnect(SilcClient client, SilcClientConnection conn,
134                 SilcStatus status, const char *message)
135 {
136
137 }
138
139
140 /* Find authentication method and authentication data by hostname and
141    port. The hostname may be IP address as well. When the authentication
142    method has been resolved the `completion' callback with the found
143    authentication method and authentication data is called. The `conn'
144    may be NULL. */
145
146 static void
147 silc_get_auth_method(SilcClient client, SilcClientConnection conn,
148                      char *hostname, SilcUInt16 port, SilcGetAuthMeth completion,
149                      void *context)
150 {
151
152 }
153
154
155 /* Verifies received public key. The `conn_type' indicates which entity
156    (server, client etc.) has sent the public key. If user decides to trust
157    the key may be saved as trusted public key for later use. The
158    `completion' must be called after the public key has been verified. */
159
160 static void
161 silc_verify_public_key(SilcClient client, SilcClientConnection conn,
162                        SilcSocketType conn_type, unsigned char *pk,
163                        SilcUInt32 pk_len, SilcSKEPKType pk_type,
164                        SilcVerifyPublicKey completion, void *context)
165 {
166
167 }
168
169
170 /* Ask (interact, that is) a passphrase from user. The passphrase is
171    returned to the library by calling the `completion' callback with
172    the `context'. The returned passphrase SHOULD be in UTF-8 encoded,
173    if not then the library will attempt to encode. */
174
175 static void
176 silc_ask_passphrase(SilcClient client, SilcClientConnection conn,
177                     SilcAskPassphrase completion, void *context)
178 {
179
180 }
181
182
183 /* Notifies application that failure packet was received.  This is called
184    if there is some protocol active in the client.  The `protocol' is the
185    protocol context.  The `failure' is opaque pointer to the failure
186    indication.  Note, that the `failure' is protocol dependant and
187    application must explicitly cast it to correct type.  Usually `failure'
188    is 32 bit failure type (see protocol specs for all protocol failure
189    types). */
190
191 static void
192 silc_failure(SilcClient client, SilcClientConnection conn,
193              SilcProtocol protocol, void *failure)
194 {
195
196 }
197
198
199 /* Asks whether the user would like to perform the key agreement protocol.
200    This is called after we have received an key agreement packet or an
201    reply to our key agreement packet. This returns TRUE if the user wants
202    the library to perform the key agreement protocol and FALSE if it is not
203    desired (application may start it later by calling the function
204    silc_client_perform_key_agreement). If TRUE is returned also the
205    `completion' and `context' arguments must be set by the application. */
206
207 static int
208 silc_key_agreement(SilcClient client, SilcClientConnection conn,
209                    SilcClientEntry client_entry, const char *hostname,
210                    SilcUInt16 port, SilcKeyAgreementCallback *completion,
211                    void **context)
212 {
213
214 }
215
216
217 /* Notifies application that file transfer protocol session is being
218    requested by the remote client indicated by the `client_entry' from
219    the `hostname' and `port'. The `session_id' is the file transfer
220    session and it can be used to either accept or reject the file
221    transfer request, by calling the silc_client_file_receive or
222    silc_client_file_close, respectively. */
223
224 static void
225 silc_ftp(SilcClient client, SilcClientConnection conn,
226          SilcClientEntry client_entry, SilcUInt32 session_id,
227          const char *hostname, SilcUInt16 port)
228 {
229
230 }
231
232
233 /* Delivers SILC session detachment data indicated by `detach_data' to the
234    application.  If application has issued SILC_COMMAND_DETACH command
235    the client session in the SILC network is not quit.  The client remains
236    in the network but is detached.  The detachment data may be used later
237    to resume the session in the SILC Network.  The appliation is
238    responsible of saving the `detach_data', to for example in a file.
239
240    The detachment data can be given as argument to the functions
241    silc_client_connect_to_server, or silc_client_add_connection when
242    creating connection to remote server, inside SilcClientConnectionParams
243    structure.  If it is provided the client library will attempt to resume
244    the session in the network.  After the connection is created
245    successfully, the application is responsible of setting the user
246    interface for user into the same state it was before detaching (showing
247    same channels, channel modes, etc).  It can do this by fetching the
248    information (like joined channels) from the client library. */
249
250 static void
251 silc_detach(SilcClient client, SilcClientConnection conn,
252             const unsigned char *detach_data, SilcUInt32 detach_data_len)
253 {
254
255 }
256
257
258 /* The SilcClientOperation structure containing the operation functions.
259    You will give this as an argument to silc_client_alloc function. */
260 SilcClientOperations ops = {
261   silc_say,
262   silc_channel_message,
263   silc_private_message,
264   silc_notify,
265   silc_command,
266   silc_command_reply,
267   silc_connect,
268   silc_disconnect,
269   silc_get_auth_method,
270   silc_verify_public_key,
271   silc_ask_passphrase,
272   silc_failure,
273   silc_key_agreement,
274   silc_ftp,
275   silc_detach
276 };