1 <big><b>Porting from Toolkit 1.0 to 1.1</b></big>
4 This documents describes the differences between the SILC Toolkit 1.0 and
5 1.1 and should help application programmers to port their SILC applications
6 to the new Toolkit version.
9 <li><a href="#general">General</a><br />
10 <li><a href="#platform">Platform changes</a>
11 <li><a href="#client">Client library</a><br />
12 <li><a href="#util">Utility library</a><br />
13 <li><a href="#apputil">Application utility library</a>
14 <li><a href="#crypto">Crypto library</a>
15 <li><a href="#skr">Key Repository library</a>
16 <li><a href="#vcard">VCard library</a>
17 <li><a href="#http">HTTP library</a>
18 <li><a href="#asn1">ASN.1 library</a>
21 <h3><a name="general"></a>General changes</h3>
23 The main SILC Toolkit header file has changed its name from silcincludes.h
24 to silc.h. The first task in porting from 1.0 to 1.1 is to change these
25 filenames in your source tree.
29 <h3><a name="platform"></a>Platform changes</h3>
31 The Windows support has been made better by improving the SILC scheduler
32 and network routines. Calling silc_net_win32_init and silc_net_win32_uninit
33 is not needed anymore. The network routines on Windows are enabled
38 <h3><a name="client"></a>Client library, lib/silcclient/</h3>
40 The client library in Toolkit 1.1 has been partially rewritten. It was
41 rewritten to work out some technical issues and to increase performance
42 and decrease memory consumption. The client library API has also faced
43 some changes, altough most of it has remained the same. Most major change
44 in the client library is that is now fully supports multiple threads. In
45 the past making multithreaded SILC client application was always a bit hard
46 but with Toolkit 1.1 it should be relatively straightforward.
48 <h4>SilcClientOperations structure</h4>
50 The SilcClientOperation structure has changed significantly. It no longer
51 has `connected', `disconnected' and `failure' function pointers. Instead a
52 new SilcClientConnectCallback has been defined that is given as argument to
53 functions like silc_client_connect_to_server, silc_client_connect_to_client
54 and silc_client_key_exchange (last two being entirely new functions in the
55 API). That callback is called when connection is established and when it
56 is disconnected, or if a protocol failure occurred during connecting. That
57 callback also delivers a detailed error information when error occurs. New
58 connection related status types in SilcClientConnectionStatus has also been
59 added, see the API for the details.
62 Also the `detach' client operation function pointer has been removed. Instead
63 the detachment data is now simply delivered in the SILC_COMMNAD_DETACH
67 Some of the remaining client operation function pointers have changed a bit.
68 Most major change is the `command' operation now having the arguments that
69 user gave on the user interface sent back to application. The `command_reply'
70 does not anymore include the SilcCommandPayload as an argument. Also the
71 variable argument lis is now delivered as va_list. Also the boolean
72 success indicator is removed and SilcStatus error argument instead is telling
73 the exact error if the SilcStatus status is other than SILC_STATUS_OK.
76 The `get_auth_method' client operation now includes the authentication method
77 that has been resolved from the remote server. The application no longer
78 needs to resolve it and the function silc_client_request_authentication_method
79 has been removed from the API.
82 The `verify_public_key' client operation now include the SilcPublicKey pointer
83 instead of the public key in raw encoded form. Also the connection type
84 argument has changed to SilcConnectionType.
87 The `key_agreement' client operation now includes a new protocol argument
88 which tells whether the key agremeent is supposed to be done on TCP or on
89 UDP transport. The new Toolkit 1.1 supports both.
93 The SilcClientParams includes new fields and some fields have been removed
94 or moved to other places. All connection timeout related fields have been
95 moved to SilcClientConnectionParams. The nickname_parse callback pointer has
96 also been removed from SilcClientParams. The Toolkit 1.1 now automatically
97 parses formatted nicknames.
100 The new field boolean `threads' can be used to tell whether the new SilcClient
101 is to use multiple threads or not. If threads support has been compiled in
102 and that field is set to TRUE then the client library will create new thread
103 for each new connection to a remote host. If you are going to use several
104 connections or some of the connections are high throughput connections (like
105 multimedia connections) then using threads is recommended for performance.
106 Note that your application needs to be multithreaded and, if necessary to,
107 perform concurrencly control in client operation callbacks which may be
108 called from multiple threads at the same time for different connections.
109 However, it is always guaranteed that for one connection the client
110 operations cannot be called from multiple threads. The multithreads
111 support in Toolkit 1.1 client library means that each new connection and
112 everything related to that connection is handled in own dedicated thread.
115 The silc_client_init function now takes several new arguments. It now takes
116 the username, hostname and realname as argument that used to be required
117 by the application to update directly to SilcClient pointer. This is not
118 longer required. Also the nickname is no longer required to be put to
119 SilcClient context as it has been made SilcClientConnection specific.
120 The function also takes a SilcClientRunning callback as argument which will
121 be called when the client library is running. Only after the callback is
122 delivered may the application start using other client library API functions.
123 For example, connecting to a server will fail if it is performed before
124 the SilcClientRunning callback is called. The callback is called after the
125 silc_client_run or silc_client_run_one has been called.
128 The silc_client_stop function takes new SilcClientStopped callback as
129 argument, and it will be called after the client library has been completely
130 stopped. The application should not quit before that is called in order
131 to clean up all resources allocation by the client library.
134 It is also not required to put the public key pair (SilcPublicKey and
135 SilcPrivateKey) into SilcClient. They have been made connection specific so
136 you simply give them as argument when you create new connection. This way
137 it is now possible to use different key pairs with different connections,
138 one that was not possible in Toolkit 1.0 without creating new SilcClient
139 instance for each new connection.
141 <h4>SilcClientConnection</h4>
143 The SilcClientConnection represents connection to a remote host. In new
144 Toolkit 1.1 this structure now includes all connection related data and
145 no connection related data is anymore included in SilcClient. For this
146 reason it is no longer necessary to create multiple SilcClient instances
147 just because you want to create multiple connections.
150 The SilcClientConnectionParams structure has many new fields. This structure
151 is given as argument to any function that is able to create a new connection
152 or to create a network listener or to create a new SILC sessions. See the
153 API documentation for all the details but the following one field of special
154 relevance when creating new SILC server connections. The nickname field is
155 now included in this structure and it is the nickname user would like to
156 initially use in the SILC network.
159 The functions silc_client_connect_to_server, silc_client_connect_to_client
160 and silc_client_key_exchange can all be used to create new SILC session with
161 a remote. To connect SILC server use silc_client_connect_to_server. You
162 now give the SilcClientCnnectionParams as argument which includes the nickname
163 user wants to use, you now can give the public key pair as argument that is
164 to be used in the connecting. The new SilcClientConnectCallback will be
165 called once the connection has been established and it delivers the
166 SilcClientConection context to the application. It will be later called
167 again to indicated disconnection from the remote host. These functions
168 now return SilcAsyncOperation context which can be used to cancel the
169 connecting, if necessary. In the past canceling connection was not possible.
173 SilcAsyncOperations op;
174 SilcClientConnectionParams params;
176 memset(¶ms, 0, sizeof(params));
178 /* Set nickname user wants to use */
179 params.nickname = nickname;
181 /* Set perfect forward secery for key exchange */
184 /* Example of creating, and then canceling a connection */
185 op = silc_client_connect_to_server(client, params, public_key, private_key,
186 remote_host, remote_port, connection_cb,
189 fatal("Connecting failed immediately"));
195 /* Cancel connecting. After canceling the `connection_cb' will not be
197 silc_async_abort(op);
201 The old function silc_client_start_key_exchange has been replaced with
202 silc_client_key_exchange function. Semantically it is equivalent to
203 silc_client_connect_to_server but it does not create new connection. Instead,
204 it accepts SilcStream as argument which is already established connection
205 to a remote host and it merely starts the key exchange. See an example
206 in the API documentation on how to use the silc_client_key_exchange, if
207 your application wishes itself to create connection instead of using the
208 client library to do it.
210 The functions silc_client_add_connection, silc_client_del_connection and
211 silc_client_del_socket has been removed. They are no longer needed.
215 Just like in Toolkit 1.0 we now have SilcClientEntry to represent user,
216 SilcChannelEntry to represent channel and SilcServerEntry to represent
217 server. In the past these structures and all API functions that dealt
218 with them were in <a href="silcclient.html">silcclient.h</a> file. They
219 are now in <a href="silcclient_entry.html">silcclient_entry.h</a> in
223 As an general convention each of these new entries now are reference
224 counted and they have locks when using them in multithreaded application.
225 Even in one-threaded application the application must always acquire a
226 reference of the entry if it wishes to save the entry pointer in the
227 application. The reference must be released once the entry pointer is
228 not needed anymore. This ensures that the library cannot free the entry
229 pointer underneath the application. An own API for taking and releasing
230 the reference is in Toolkit 1.1.
234 /* Take reference of the client entry I save to my own context. */
235 my_context->client_entry = silc_client_ref_client(client, conn, client_entry);
239 If multiple threads are used and application wants to access the entry it
240 must always first lock the entry. After application has read the information
241 it needs from the entry it must release the entry lock. The entry lock
242 should be held only for short periods of time and failure to release the
243 lock will result into deadlock. An own API for taking and releasing the
244 entry lock is in Toolkit 1.1. If you application is not multithreaded
245 you do not need to use the entry locking.
249 /* Read data from client entry in multithreaded environment */
250 silc_client_lock_client(client_entry);
251 fprintf(stdout, "%s\n", client_entry->nickname);
252 fprintf(stdout, "%s\n", silc_id_render(SILC_ID_CLIENT, &client_entry->id));
253 silc_client_unlock_client(client_entry);
257 From the entries all unnecessary information for application has been either
258 removed or moved to internal structure that is not accessible by the
259 application. As a result the entry structures are much smaller and cleaner.
262 The SilcClientEntry now includes nickname_normalized field and it is the
263 normalized version of the user's nickname, in case application needs it.
264 It is also guaranteed in Toolkit 1.1 that the nickname inside SilcCientEntry
265 is always valid nickname.
268 The SilcChannelEntry now includes new channel_pubkeys list, which includes
269 the channel public keys if they have added to the channel. This information
270 was not present in Toolkit 1.0.
273 The SilcServerEntry now includes new field public_key, which is the server's
274 public key if we have resolved it. This information was not present in
278 In Toolkit 1.1 it is now easier to search and resolve entries. As a new
279 feature it now also possible to search and resolve server entries from the
280 SILC network. See the API documentation for all the details on searching
281 entries from the client library cache and from the SILC network.
283 <h4>Sending/Receiving messages</h4>
285 Sending messages has not much changed from the Toolkit 1.1. In Toolkit 1.1
286 the message may now safely be sent in from multiple threads for same client
287 or for same channel. In case the message are digitally signed the hash
288 function used in the signature computation must now be given as argument.
289 If this is done in multiple threads, each thread must use different SilcHash
290 context because SilcHash does not support multiple threads. Simply allocate
291 new SilcHash for each thread where you send digitally signed messages.
294 Receiving message is same as in Toolkit 1.0. You receive private_message
295 or channel_message client operation. It is always guaranteed that even in
296 multithreaded application the messages are received in one thread. You need
297 concurrency control in your application only if you access shared data in
298 your client operation callbacks.
301 In Toolkit 1.1 as a new feature it is also possible to wait for incoming
302 private messages in a thread. New function silc_client_private_message_wait
303 can be used to block the calling process or thread until private message
304 for the specified client is received.
306 <h4>Calling and sending commands</h4>
308 Just like in Toolkit 1.0 in Toolkit 1.1 you can call command implemented
309 inside the client library with silc_client_command_call. The command_reply
310 client operation will be called once the command reply has arrived.
313 As a major change in semantics of sending commands with the
314 silc_client_command_send function is the way the command reply is handled
315 in Toolkit 1.1. In the new Toolkit the command_reply client operation will
316 not be anymore called for commands that has been sent with
317 silc_client_command_send. The command_reply client operation is called only
318 when silc_client_command_call function is used. With silc_client_command_send
319 you can give the command reply callback, SilcClientCommandReply, as argument,
320 and it will be called for each command reply that is received from the
324 Just likein 1.0 in 1.1 it is also possible to attach to pending commands
325 by using silc_client_command_pending. As a difference to 1.0 the command
326 identifier is not anymore available to application from the
327 SilcClientConnection context. Instead the silc_client_command_call and
328 silc_client_command_send return the command identifier, and application needs
329 to save it in order to be able to attach to it at later time. However,
330 this feature is not expected to be very important for application
331 programmers as the new silc_client_command_send already includes the
332 command reply callback.
336 Comparison between 1.0 and 1.1
339 /* Send ping command. The reply will be in the attached command reply
340 and in the command_reply client operation. */
341 silc_client_command_send(client, conn, SILC_COMMAND_PING, ++conn->cmd_ident,
342 1, 1, server_id, server_id_len);
343 silc_client_command_pending(conn, SILC_COMMAND_PING, conn->cmd_ident,
344 ping_command_reply, context);
347 /* Send ping command. The reply will be ping_command_reply function. */
348 silc_client_command_send(client, conn, SILC_COMMAND_PING,
349 ping_command_reply, context,
350 1, 1, server_id, server_id_len);
354 <h4>Notify arguments</h4>
356 In Toolkit 1.1 the following notify arguments have had changes. See
357 the <a href="notifyargs.html">Notify Arguments</a> for details. You should
358 go through your application and change the handling of the following notify
359 messages for Toolkit 1.1.
362 SILC_NOTIFY_TYPE_NICK_CHANGE<br />
363 SILC_NOTIFY_TYPE_CMODE_CHANGE<br />
364 SILC_NOTIFY_TYPE_SIGNOFF<br />
365 SILC_NOTIFY_TYPE_SERVER_SIGNOFF<br />
368 The basic changes in notify arguments from Toolkit 1.0 is that the
369 Toolkit 1.1 parses various lists and other raw data for the application as
370 opposed to sending them in the raw format. This makes programming easier.
372 <h4>Command reply arguments</h4>
374 In Toolkit 1.1 the following command reply arguments have had changes. See
375 the <a href="command_reply_args.html">Command Reply Arguments</a> for
376 details. You should go through your application and change the handling
377 of the following command replies for Toolkit 1.1.
380 SILC_COMMAND_WHOIS<br />
381 SILC_COMMAND_INVITE<br />
382 SILC_COMMAND_STATS<br />
383 SILC_COMMAND_JOIN<br />
384 SILC_COMMAND_CMODE<br />
385 SILC_COMMAND_BAN<br />
386 SILC_COMMAND_DETACH<br />
387 SILC_COMMAND_USERS<br />
390 The basic changes in command reply arguments from Toolkit 1.0 is that the
391 Toolkit 1.1 parses various lists and other raw data for the application as
392 opposed to sending them in the raw format.. This makes programming easier.
394 <h4>Other changes in client library</h4>
396 There are many other smaller changes in Toolkit 1.1 that require you to
397 change your application when porting from Toolkit 1.0. We are not listing
398 all of them here but briefly mention some API changes.
401 Listing channel private keys now return SilcDList instead of an array.
404 The key agreement API has changed a little bit and is now more cleaner and
405 supports all the features that are needed in full featured key agreement.
406 The silc_client_peform_key_agreement_fd has been replaced by
407 silc_client_perform_key_agreement_stream.
410 The private message key API has slight changes also. It is no longer
411 necessary for the caller to specify whether the private message key is for
412 responder or initiator use.
415 The file transfer API has changed a little bit and is now more cleaner and
416 supports all the features that are needed in full featured file transfer.
417 It is now easier to send files when you are behind NAT when you can
418 specifically define the IPs that are used in both file sending and
422 As a new function silc_client_nickname_format can now be used to format
423 the nickname of a client entry. The client library automatically formats
424 the nicknames but in some cases application might like to change the
425 nickname of a certain client entry.
429 <h3><a name="util"></a>Utility library, lib/silcutil/</h3>
431 The Utility library (runtime library) has had several changes and has several
432 new interfaces. Some interfaces has also been removed or moved to some
433 other library. Removed interfaces rae: silcprotocol.h and silcsockconn.h.
434 Moved interfaces are: <a href="silcapputil.html">silcapputil.h</a> and
435 <a href="silcvcard.html">silcvcard.h</a>.
437 <h4>SILC Async Operation Interface</h4>
439 A new asynchronous operation API (<a href="silcasync.html">silcasync.h</a>)
440 has been added. It can be used to control asynchronous operations, like
441 to cancel them. Many asynchronous routines in SILC Toolkit now return
442 SilcAsyncOperation context so that the operation can be controlled by the
443 caller. It especiallly provides a generic way to cancel asynchronous
444 operations which can be difficult.
446 <h4>SILC Atomic Operations Interface</h4>
448 A new atomic operations API (<a href="silcatomic.html">silcatomic.h</a>)
449 has been added. It provides routines to perform various operations on
450 integeres and pointers atomically.
452 <h4>SILC Data Stack Interface</h4>
454 A new data stack (memory pool system) API
455 (<a href="silcstack.html">silcstack.h</a>) has been added.
456 It provides a fast memory allocation system. Many routines in the SILC Toolkit
457 are SilcStack aware thus enabling them to use the SilcStack as their source
458 for memory allocation. All routines that are SilcStack aware automatically
459 revert back to normal memory allocation if SilcStack is not given as
460 argument. See silcstack.h for list of utility routines that support SilcStack
463 <h4>SILC Condition Variable Interface</h4>
465 A new condition variable API (<a href="silccond.html">silccond.h</a>)
466 has been added. It provides condition variables for multithreaded
469 <h4>SILC Stream Interface</h4>
471 A new abstract stream API (<a href="silcstream.html">silcstream.h</a>)
472 has been added. The SilcStream
473 provides an abstract way of representing different kinds of streams. The
474 API provides functions that can be used to read, write, control and destroy
475 streams. The API is not used to create streams but separate interfaces
476 exist for streams that use the SilcStream abstraction. For example,
477 socket stream and file descriptor stream exist.
479 <h4>SILC FD Stream Interface</h4>
481 A new file descriptor stream API
482 (<a href="silcfdstream.html">silcfdstream.h</a>) has been added. It
483 provides a blocking and non-blocking file descriptor stream through the
484 SilcStream abstraction.
486 <h4>SILC Socket Stream Interface</h4>
488 A new socket stream API
489 (<a href="silcsocketstream.html">silcsocketstream.h</a>) has been added.
490 It provides a blocking and non-blocking socket stream through the SilcStream
493 <h4>SILC FSM Interface</h4>
495 A new Finite State Machine API
496 (<a href="silcfsm.html">silcfsm.h</a>) has been added. It provides
497 an FSM that can be used to implement all kinds of machines and protocols.
498 The machine also supports threads, and threads that are actually executed
499 in real system threads. The SILC FSM API also supports asynchronous
502 <h4>SILC Time Interface</h4>
505 (<a href="silctime.html">silctime.h</a>) has been added. It provides utility
506 functions to retrieve and represent time in different ways. It supports
507 Universal and Generalized time string creation and parsing and adds a new
508 SilcTime structure to represent time.
510 <h4>SILC Snprintf Interface</h4>
513 (<a href="silcsnprintf.html">silcsnprintf.h</a>) has been added. It
514 provides snprintf and other string formatting routines.
516 <h4>SILC Mutex Interface changes</h4>
518 The SILC Mutex API (<a href="silcmutex.html">silcmutex.h</a>)
519 has several changes. A support for read/write locks has been added
520 (SilcRwLock). Also silc_mutex_assert_locked function is added.
522 <h4>SILC Network Interface changes</h4>
525 (<a href="silcnet.html">silcnet.h</a>) has several changes. The API is almost
526 entirely rewritten and most of the old functions have been removed. The
527 API has now both TCP and UDP support, and as previously supports IPv4
528 and IPv6. New functions are silc_net_tcp_create_listener,
529 silc_net_listener_get_port, silc_net_close_listener, silc_net_tcp_connnect,
530 silc_net_udp_connect, silc_net_udp_receive, silc_net_udp_send.
532 <h4>SILC Scheduler Interface changes</h4>
534 The SILC Schedule API
535 (<a href="silcschedule.html">silcschedule.h</a>) has several changes. The
536 scheduler has been entirely rewritten but most of the API remains the same.
537 The SILC_TASK_GENERIC and SILC_TASK_CALLBACK_GLOCAL have been removed.
538 The way signal are dispatched has been changed. The SILC Schedule is now
539 able to itself dispatch all signals. New functions are
540 silc_schedule_task_add_fd, silc_schedule_task_add_timeout,
541 silc_schedule_task_add_signal, silc_task_del_by_all,
542 silc_schedule_get_fd_events. The functions silc_schedule_signal_register,
543 silc_schedule_signal_unregister and silc_schedule_signal_call have been
546 <h4>SILC Types Interface changes</h4>
548 The SILC Type API (<a href="silctypes.html">silctypes.h</a>) has several
549 changes. The bool type is replaced with SilcBool. Sockets are now
550 represented by SilcSocket.
552 <h4>SILC String util Interface changes</h4>
554 The SILC string utility API
555 (<a href="silcstrutil.html">silcstrutil.h</a>) has changes. The PEM encoding
556 and decoding routines has been renamed, silc_base64_encode,
557 silc_base64_encode_file and silc_base64_decode. The silc_mime_parse has
558 been removed. A new silc_string_split function has been added.
560 <h4>SILC Utility Interface changes</h4>
563 <h4>SILC File Util Interface changes</h4>
565 The SILC file utility API (<a href="silcfileutil.html">silcfileutil.h</a>)
566 has changes. A new function silc_file_set_nonblock has been added.
568 <h4>SILC List and Dynamic List Interface changes</h4>
570 The SILC List (<a href="silclist.html">silclist.h</a>) and SILC Dynamic List
571 (silcdlist.h) APIs have changes. New functions silc_list_insert and
572 silc_dlist_insert have been added.
574 <h4>SILC Buffer Interface changes</h4>
576 The SILC Buffer API (<a href="silcbuffer.html">silcbuffer.h</a>) has several
577 changes. The SilcBuffer
578 structure no longer contain the buffer length and true length fields
579 but silc_buffer_len() and silc_buffr_truelen() macros are available
580 instead. Also silc_buffer_data(), silc_buffer_datalen(), silc_buffer_purge(),
581 silc_buffer_reset(), silc_buffer_start(), silc_buffer_end() and
582 silc_buffer_enlarge() has been added. The API also supports SilcStack.
584 <h4>SILC Buffer Formatting Interface changes</h4>
586 The SILC Buffer Formatting API
587 (<a href="silcbuffmt.html">silcbuffmt.h</a>) has several changes. The
588 silc_buffer_format now automatically allocates memory to the destination
589 buffer if it does not have space. Also new the following new formatters
590 have been added: SILC_STR_DATA (replaces SILC_STR_UI_XNSTRING),
591 SILC_STR_BUFFER, SILC_STR_FUNC, SILC_STF_OFFSET and SILC_STR_ADVANCE.
592 The API also supports SilcStack.
594 <h4>SILC Memory Interface changes</h4>
596 The memory allocation API (<a href="silcmemory.html">silcmemory.h</a>) has
597 several changes. It supports now SilcStack as memory source. Also all
598 memory allocation routines can now fail and return NULL as opposed to fatally
599 failing when memory allocation fails.
602 <h3><a name="apputil"></a>SILC Application Utility library, lib/silcapputil/</h3>
604 A new SILC Application Utility library has been added. It provides
605 various application specific utility libraries that are not part of
606 the runtime library (lib/silcutil/). The interfaces in the Application
607 utility library were in other libraries in Toolkit 1.0 and the library
608 does not contain any entirely new interfaces.
610 <h4>SILC Application Utility Interface</h4>
612 The <a href="silcapputil.html">silcapputil.h</a> contains various application
613 utility functions. It
614 existed in Toolkit 1.0 but some of the APIs has been changed. The
615 silc_create_key_pair, silc_load_key_pair and silc_show_public_key APIs
616 has changed. A new silc_show_public_key_file has been added. Functions
617 silc_identifier_check, silc_identifier_verify, silc_channel_name_check,
618 silc_channel_name_verify, silc_get_mode_list silc_get_status_message,
619 silc_get_packet_name, silc_get_command_name, silc_parse_version_string,
620 silc_version_to_num, silc_client_chmode, silc_client_chumode,
621 silc_client_chumode_char and silc_id_render has been moved from other
622 libraries into this interface in Toolkit 1.1.
624 <h4>SILC ID Cache Interface</h4>
626 The ID Cache interface (<a href="silcidcache.html">silcidcache.h</a>) has
627 been moved from lib/silccore into lib/silcapputil/.
630 <h3><a name="skr"></a>SILC Key Repository library, lib/silcskr/</h3>
632 A new SILC Key Repository library has been added. The library provides
633 a SILC Key Repository API (<a href="silcskr.html">silcskr.h</a>) which provides
634 a repository for storing and retrieving public keys.
637 <h3><a name="vcard"></a>SILC VCard library, lib/silcvcard/</h3>
639 A new SILC VCard library has been added. The SILC VCard API has been
640 moved from utility library to own library in lib/silcvcard/.
643 <h3><a name="http"></a>SILC HTTP library, lib/silchttp/</h3>
645 A new SILC HTTP library has been added. The library includes SILC HTTP
646 Server Interface and SILC HTTP PHP Translator Interface.
648 <h4>SILC HTTP Server Interface</h4>
650 The SILC HTTP Server API (<a href="silchttpserver.html">silchttpservder.h</a>)
651 provides a simple HTTP server implementation for applications that want to
652 integrate a small HTTP server.
654 <h4>SILC HTTP PHP Translator Interface</h4>
656 The SILC HTTP PHP Translator API (<a href="silchttpphp.html">silchttpphp.h</a>)
657 provides PHP translates PHP code into HTML. It can be used to serve PHP
658 pages in HTTP server.
661 <h3><a name="asn1"></a>SILC ASN.1 library, lib/silcasn1/</h3>
663 A new Abstract Syntax Notation One (ASN.1) library has been added. The
664 library provides SILC ASN.1 encoder and decoder interface and SILC BER
665 encoder and decoder interface.
667 <h4>SILC ASN.1 Interface</h4>
669 The SILC ASN.1 API (<a href="silcasn1.html">silcasn1.h</a>) provides ASN.1
670 encoder and decoder. The interface provides efficient encoder and decoder
671 and is support SilcStack as memory source. The interface is simple and it
672 supports almost all ASN.1 features.
674 <h4>SILC BER Interface</h4>
676 The SILC BER API (<a href="silcber.html">silcber.h</a>) provides BER/DER
677 encoder and decoder. It is integral part of the ASN.1 library and the ASN.1