-<big><b>Porting from Toolkit 1.0 to 1.1</b></big>
-
-<br /> <br />
-This documents describes the differences between the SILC Toolkit 1.0 and
-1.1 and should help application programmers to port their SILC applications
-to the new Toolkit version.
-
-<br /> <br />
-<li><a href="#general">General</a><br />
-<li><a href="#platform">Platform changes</a>
-<li><a href="#client">Client library</a><br />
-<li><a href="#util">Utility library</a><br />
-<li><a href="#apputil">Application utility library</a>
-<li><a href="#crypto">Crypto library</a>
-<li><a href="#skr">Key Repository library</a>
-<li><a href="#vcard">VCard library</a>
-<li><a href="#http">HTTP library</a>
-<li><a href="#asn1">ASN.1 library</a>
-
-<br /> <br />
-<h3><a name="general"></a>General changes</h3>
-
-The main SILC Toolkit header file has changed its name from silcincludes.h
-to silc.h. The first task in porting from 1.0 to 1.1 is to change these
-filenames in your source tree.
-
-
-<br /> <br />
-<h3><a name="platform"></a>Platform changes</h3>
-
-The Windows support has been made better by improving the SILC scheduler
-and network routines. Calling silc_net_win32_init and silc_net_win32_uninit
-is not needed anymore. The network routines on Windows are enabled
-automatically.
-
-
-<br /> <br />
-<h3><a name="client"></a>Client library, lib/silcclient/</h3>
-
-The client library in Toolkit 1.1 has been partially rewritten. It was
-rewritten to work out some technical issues and to increase performance
-and decrease memory consumption. The client library API has also faced
-some changes, altough most of it has remained the same. Most major change
-in the client library is that is now fully supports multiple threads. In
-the past making multithreaded SILC client application was always a bit hard
-but with Toolkit 1.1 it should be relatively straightforward.
-
-<h4>SilcClientOperations structure</h4>
-
-The SilcClientOperations structure has changed significantly. It no longer
-has `connected', `disconnected' and `failure' function pointers. Instead a
-new SilcClientConnectCallback has been defined that is given as argument to
-functions like silc_client_connect_to_server, silc_client_connect_to_client
-and silc_client_key_exchange (last two being entirely new functions in the
-API). That callback is called when connection is established and when it
-is disconnected, or if a protocol failure occurred during connecting. That
-callback also delivers a detailed error information when error occurs. New
-connection related status types in SilcClientConnectionStatus has also been
-added, see the API for the details.
-
-<br /> <br />
-Also the `detach' client operation function pointer has been removed. Instead
-the detachment data is now simply delivered in the SILC_COMMAND_DETACH
-command reply.
-
-<br /> <br />
-Some of the remaining client operation function pointers have changed a bit.
-Most major change is the `command' operation now having the arguments that
-user gave on the user interface sent back to application. The `command_reply'
-does not anymore include the SilcCommandPayload as an argument. Also the
-variable argument lis is now delivered as va_list. Also the boolean
-success indicator is removed and SilcStatus error argument instead is telling
-the exact error if the SilcStatus status is other than SILC_STATUS_OK.
-
-<br /> <br />
-The `get_auth_method' client operation now includes the authentication method
-that has been resolved from the remote server. The application no longer
-needs to resolve it and the function silc_client_request_authentication_method
-has been removed from the API.
-
-<br /> <br />
-The `verify_public_key' client operation now include the SilcPublicKey pointer
-instead of the public key in raw encoded form. Also the connection type
-argument has changed to SilcConnectionType.
-
-<br /> <br />
-The `key_agreement' client operation now includes a new protocol argument
-which tells whether the key agremeent is supposed to be done on TCP or on
-UDP transport. The new Toolkit 1.1 supports both.
-
-<h4>SilcClient</h4>
-
-The SilcClientParams includes new fields and some fields have been removed
-or moved to other places. All connection timeout related fields have been
-moved to SilcClientConnectionParams. The nickname_parse callback pointer has
-also been removed from SilcClientParams. The Toolkit 1.1 now automatically
-parses formatted nicknames.
-
-<br /> <br />
-The new field boolean `threads' can be used to tell whether the new SilcClient
-is to use multiple threads or not. If threads support has been compiled in
-and that field is set to TRUE then the client library will create new thread
-for each new connection to a remote host. If you are going to use several
-connections or some of the connections are high throughput connections (like
-multimedia connections) then using threads is recommended for performance.
-Note that your application needs to be multithreaded and, if necessary to,
-perform concurrencly control in client operation callbacks which may be
-called from multiple threads at the same time for different connections.
-However, it is always guaranteed that for one connection the client
-operations cannot be called from multiple threads. The multithreads
-support in Toolkit 1.1 client library means that each new connection and
-everything related to that connection is handled in own dedicated thread.
-
-<br /> <br />
-The silc_client_init function now takes several new arguments. It now takes
-the username, hostname and realname as argument that used to be required
-by the application to update directly to SilcClient pointer. This is not
-longer required. Also the nickname is no longer required to be put to
-SilcClient context as it has been made SilcClientConnection specific.
-The function also takes a SilcClientRunning callback as argument which will
-be called when the client library is running. Only after the callback is
-delivered may the application start using other client library API functions.
-For example, connecting to a server will fail if it is performed before
-the SilcClientRunning callback is called. The callback is called after the
-silc_client_run or silc_client_run_one has been called.
-
-<br /> <br />
-The silc_client_stop function takes new SilcClientStopped callback as
-argument, and it will be called after the client library has been completely
-stopped. The application should not quit before that is called in order
-to clean up all resources allocation by the client library.
-
-<br /> <br />
-It is also not required to put the public key pair (SilcPublicKey and
-SilcPrivateKey) into SilcClient. They have been made connection specific so
-you simply give them as argument when you create new connection. This way
-it is now possible to use different key pairs with different connections,
-one that was not possible in Toolkit 1.0 without creating new SilcClient
-instance for each new connection.
-
-<h4>SilcClientConnection</h4>
-
-The SilcClientConnection represents connection to a remote host. In new
-Toolkit 1.1 this structure now includes all connection related data and
-no connection related data is anymore included in SilcClient. For this
-reason it is no longer necessary to create multiple SilcClient instances
-just because you want to create multiple connections.
-
-<br /> <br />
-The SilcClientConnectionParams structure has many new fields. This structure
-is given as argument to any function that is able to create a new connection
-or to create a network listener or to create a new SILC sessions. See the
-API documentation for all the details but the following one field of special
-relevance when creating new SILC server connections. The nickname field is
-now included in this structure and it is the nickname user would like to
-initially use in the SILC network.
-
-<br /> <br />
-The functions silc_client_connect_to_server, silc_client_connect_to_client
-and silc_client_key_exchange can all be used to create new SILC session with
-a remote. To connect SILC server use silc_client_connect_to_server. You
-now give the SilcClientConnectionParams as argument which includes the
-nicknameuser wants to use, you now can give the public key pair as argument that is
-to be used in the connecting. The new SilcClientConnectCallback will be
-called once the connection has been established and it delivers the
-SilcClientConection context to the application. It will be later called
-again to indicated disconnection from the remote host. These functions
-now return SilcAsyncOperation context which can be used to cancel the
-connecting, if necessary. In the past canceling connection was not possible.
-
-<br /> <br />
-<pre>
-SilcAsyncOperation op;
-SilcClientConnectionParams params;
-
-memset(¶ms, 0, sizeof(params));
-
-/* Set nickname user wants to use */
-params.nickname = nickname;
-
-/* Set perfect forward secery for key exchange */
-params.pfs = TRUE;
-
-/* Example of creating, and then canceling a connection */
-op = silc_client_connect_to_server(client, params, public_key, private_key,
- remote_host, remote_port, connection_cb,
- app_context);
-if (!op) {
- fatal("Connecting failed immediately"));
- exit(1);
-}
-
-...
-
-/* Cancel connecting. After canceling the `connection_cb' will not be
- called. */
-silc_async_abort(op);
-</pre>
-
-<br /> <br />
-The old function silc_client_start_key_exchange has been replaced with
-silc_client_key_exchange function. Semantically it is equivalent to
-silc_client_connect_to_server but it does not create new connection. Instead,
-it accepts SilcStream as argument which is already established connection
-to a remote host and it merely starts the key exchange. See an example
-in the API documentation on how to use the silc_client_key_exchange, if
-your application wishes itself to create connection instead of using the
-client library to do it.
-
-The functions silc_client_add_connection, silc_client_del_connection and
-silc_client_del_socket has been removed. They are no longer needed.
-
-<h4>Entries</h4>
-
-Just like in Toolkit 1.0 we now have SilcClientEntry to represent user,
-SilcChannelEntry to represent channel and SilcServerEntry to represent
-server. In the past these structures and all API functions that dealt
-with them were in <a href="silcclient.html">silcclient.h</a> file. They
-are now in <a href="silcclient_entry.html">silcclient_entry.h</a> in
-Toolkit 1.1.
-
-<br /> <br />
-As an general convention each of these new entries now are reference
-counted and they have locks when using them in multithreaded application.
-Even in one-threaded application the application must always acquire a
-reference of the entry if it wishes to save the entry pointer in the
-application. The reference must be released once the entry pointer is
-not needed anymore. This ensures that the library cannot free the entry
-pointer underneath the application. An own API for taking and releasing
-the reference is in Toolkit 1.1.
-
-<br /> <br />
-<pre>
-/* Take reference of the client entry I save to my own context. */
-my_context->client_entry = silc_client_ref_client(client, conn, client_entry);
-</pre>
-
-<br /> <br />
-If multiple threads are used and application wants to access the entry it
-must always first lock the entry. After application has read the information
-it needs from the entry it must release the entry lock. The entry lock
-should be held only for short periods of time and failure to release the
-lock will result into deadlock. An own API for taking and releasing the
-entry lock is in Toolkit 1.1. If you application is not multithreaded
-you do not need to use the entry locking.
-
-<br /> <br />
-<pre>
-/* Read data from client entry in multithreaded environment */
-silc_client_lock_client(client_entry);
-fprintf(stdout, "%s\n", client_entry->nickname);
-fprintf(stdout, "%s\n", silc_id_render(SILC_ID_CLIENT, &client_entry->id));
-silc_client_unlock_client(client_entry);
-</pre>
-
-<br /> <br />
-From the entries all unnecessary information for application has been either
-removed or moved to internal structure that is not accessible by the
-application. As a result the entry structures are much smaller and cleaner.
-
-<br /> <br />
-The SilcClientEntry now includes nickname_normalized field and it is the
-normalized version of the user's nickname, in case application needs it.
-It is also guaranteed in Toolkit 1.1 that the nickname inside SilcCientEntry
-is always valid nickname.
-
-<br /> <br />
-The SilcChannelEntry now includes new channel_pubkeys list, which includes
-the channel public keys if they have added to the channel. This information
-was not present in Toolkit 1.0.
-
-<br /> <br />
-The SilcServerEntry now includes new field public_key, which is the server's
-public key if we have resolved it. This information was not present in
-Toolkit 1.0.
-
-<br /> <br />
-In Toolkit 1.1 it is now easier to search and resolve entries. As a new
-feature it now also possible to search and resolve server entries from the
-SILC network. See the API documentation for all the details on searching
-entries from the client library cache and from the SILC network.
-
-<h4>Sending/Receiving messages</h4>
-
-Sending messages has not much changed from the Toolkit 1.1. In Toolkit 1.1
-the message may now safely be sent in from multiple threads for same client
-or for same channel. In case the message are digitally signed the hash
-function used in the signature computation must now be given as argument.
-If this is done in multiple threads, each thread must use different SilcHash
-context because SilcHash does not support multiple threads. Simply allocate
-new SilcHash for each thread where you send digitally signed messages.
-
-<br /> <br />
-Receiving message is same as in Toolkit 1.0. You receive private_message
-or channel_message client operation. It is always guaranteed that even in
-multithreaded application the messages are received in one thread. You need
-concurrency control in your application only if you access shared data in
-your client operation callbacks.
-
-<br /> <br />
-In Toolkit 1.1 as a new feature it is also possible to wait for incoming
-private messages in a thread. New function silc_client_private_message_wait
-can be used to block the calling process or thread until private message
-for the specified client is received.
-
-<h4>Calling and sending commands</h4>
-
-Just like in Toolkit 1.0 in Toolkit 1.1 you can call command implemented
-inside the client library with silc_client_command_call. The command_reply
-client operation will be called once the command reply has arrived.
-
-<br /> <br />
-As a major change in semantics of sending commands with the
-silc_client_command_send function is the way the command reply is handled
-in Toolkit 1.1. In the new Toolkit the command_reply client operation will
-not be anymore called for commands that has been sent with
-silc_client_command_send. The command_reply client operation is called only
-when silc_client_command_call function is used. With silc_client_command_send
-you can give the command reply callback, SilcClientCommandReply, as argument,
-and it will be called for each command reply that is received from the
-server.
-
-<br /> <br />
-Just likein 1.0 in 1.1 it is also possible to attach to pending commands
-by using silc_client_command_pending. As a difference to 1.0 the command
-identifier is not anymore available to application from the
-SilcClientConnection context. Instead the silc_client_command_call and
-silc_client_command_send return the command identifier, and application needs
-to save it in order to be able to attach to it at later time. However,
-this feature is not expected to be very important for application
-programmers as the new silc_client_command_send already includes the
-command reply callback.
-
-<br /> <br />
-<pre>
-Comparison between 1.0 and 1.1
-
-Toolkit 1.0:
-/* Send ping command. The reply will be in the attached command reply
- and in the command_reply client operation. */
-silc_client_command_send(client, conn, SILC_COMMAND_PING, ++conn->cmd_ident,
- 1, 1, server_id, server_id_len);
-silc_client_command_pending(conn, SILC_COMMAND_PING, conn->cmd_ident,
- ping_command_reply, context);
-
-Toolkit 1.1:
-/* Send ping command. The reply will be ping_command_reply function. */
-silc_client_command_send(client, conn, SILC_COMMAND_PING,
- ping_command_reply, context,
- 1, 1, server_id, server_id_len);
-
-</pre>
-
-<h4>Notify arguments</h4>
-
-In Toolkit 1.1 the following notify arguments have had changes. See
-the <a href="notifyargs.html">Notify Arguments</a> for details. You should
-go through your application and change the handling of the following notify
-messages for Toolkit 1.1.
-
-<br /> <br />
-SILC_NOTIFY_TYPE_NICK_CHANGE<br />
-SILC_NOTIFY_TYPE_CMODE_CHANGE<br />
-SILC_NOTIFY_TYPE_SIGNOFF<br />
-SILC_NOTIFY_TYPE_SERVER_SIGNOFF<br />
-
-<br /> <br />
-The basic changes in notify arguments from Toolkit 1.0 is that the
-Toolkit 1.1 parses various lists and other raw data for the application as
-opposed to sending them in the raw format. This makes programming easier.
-
-<h4>Command reply arguments</h4>
-
-In Toolkit 1.1 the following command reply arguments have had changes. See
-the <a href="command_reply_args.html">Command Reply Arguments</a> for
-details. You should go through your application and change the handling
-of the following command replies for Toolkit 1.1.
-
-<br /> <br />
-SILC_COMMAND_WHOIS<br />
-SILC_COMMAND_INVITE<br />
-SILC_COMMAND_STATS<br />
-SILC_COMMAND_JOIN<br />
-SILC_COMMAND_CMODE<br />
-SILC_COMMAND_BAN<br />
-SILC_COMMAND_DETACH<br />
-SILC_COMMAND_USERS<br />
-
-<br /> <br />
-The basic changes in command reply arguments from Toolkit 1.0 is that the
-Toolkit 1.1 parses various lists and other raw data for the application as
-opposed to sending them in the raw format.. This makes programming easier.
-
-<h4>Other changes in client library</h4>
-
-There are many other smaller changes in Toolkit 1.1 that require you to
-change your application when porting from Toolkit 1.0. We are not listing
-all of them here but briefly mention some API changes.
-
-<br /> <br />
-Listing channel private keys now return SilcDList instead of an array.
-
-<br /> <br />
-The key agreement API has changed a little bit and is now more cleaner and
-supports all the features that are needed in full featured key agreement.
-The silc_client_peform_key_agreement_fd has been replaced by
-silc_client_perform_key_agreement_stream.
-
-<br /> <br />
-The private message key API has slight changes also. It is no longer
-necessary for the caller to specify whether the private message key is for
-responder or initiator use.
-
-<br /> <br />
-The file transfer API has changed a little bit and is now more cleaner and
-supports all the features that are needed in full featured file transfer.
-It is now easier to send files when you are behind NAT when you can
-specifically define the IPs that are used in both file sending and
-receiving.
-
-<br /> <br />
-As a new function silc_client_nickname_format can now be used to format
-the nickname of a client entry. The client library automatically formats
-the nicknames but in some cases application might like to change the
-nickname of a certain client entry.
-
-
-<br /> <br />
-<h3><a name="util"></a>Utility library, lib/silcutil/</h3>
-
-The Utility library (runtime library) has had several changes and has several
-new interfaces. Some interfaces has also been removed or moved to some
-other library. Removed interfaces rae: silcprotocol.h and silcsockconn.h.
-Moved interfaces are: <a href="silcapputil.html">silcapputil.h</a> and
-<a href="silcvcard.html">silcvcard.h</a>.
-
-<h4>SILC Async Operation Interface</h4>
-
-A new asynchronous operation API (<a href="silcasync.html">silcasync.h</a>)
-has been added. It can be used to control asynchronous operations, like
-to cancel them. Many asynchronous routines in SILC Toolkit now return
-SilcAsyncOperation context so that the operation can be controlled by the
-caller. It especiallly provides a generic way to cancel asynchronous
-operations which can be difficult.
-
-<h4>SILC Atomic Operations Interface</h4>
-
-A new atomic operations API (<a href="silcatomic.html">silcatomic.h</a>)
-has been added. It provides routines to perform various operations on
-integeres and pointers atomically.
-
-<h4>SILC Data Stack Interface</h4>
-
-A new data stack (memory pool system) API
-(<a href="silcstack.html">silcstack.h</a>) has been added.
-It provides a fast memory allocation system. Many routines in the SILC Toolkit
-are SilcStack aware thus enabling them to use the SilcStack as their source
-for memory allocation. All routines that are SilcStack aware automatically
-revert back to normal memory allocation if SilcStack is not given as
-argument. See silcstack.h for list of utility routines that support SilcStack
-by default.
-
-<h4>SILC Condition Variable Interface</h4>
-
-A new condition variable API (<a href="silccond.html">silccond.h</a>)
-has been added. It provides condition variables for multithreaded
-applications.
-
-<h4>SILC Stream Interface</h4>
-
-A new abstract stream API (<a href="silcstream.html">silcstream.h</a>)
-has been added. The SilcStream
-provides an abstract way of representing different kinds of streams. The
-API provides functions that can be used to read, write, control and destroy
-streams. The API is not used to create streams but separate interfaces
-exist for streams that use the SilcStream abstraction. For example,
-socket stream and file descriptor stream exist.
-
-<h4>SILC FD Stream Interface</h4>
-
-A new file descriptor stream API
-(<a href="silcfdstream.html">silcfdstream.h</a>) has been added. It
-provides a blocking and non-blocking file descriptor stream through the
-SilcStream abstraction.
-
-<h4>SILC Socket Stream Interface</h4>
-
-A new socket stream API
-(<a href="silcsocketstream.html">silcsocketstream.h</a>) has been added.
-It provides a blocking and non-blocking socket stream through the SilcStream
-abstraction.
-
-<h4>SILC FSM Interface</h4>
-
-A new Finite State Machine API
-(<a href="silcfsm.html">silcfsm.h</a>) has been added. It provides
-an FSM that can be used to implement all kinds of machines and protocols.
-The machine also supports threads, and threads that are actually executed
-in real system threads. The SILC FSM API also supports asynchronous
-events.
-
-<h4>SILC Time Interface</h4>
-
-A new SILC Time API
-(<a href="silctime.html">silctime.h</a>) has been added. It provides utility
-functions to retrieve and represent time in different ways. It supports
-Universal and Generalized time string creation and parsing and adds a new
-SilcTime structure to represent time.
-
-<h4>SILC Snprintf Interface</h4>
-
-A new snprintf API
-(<a href="silcsnprintf.html">silcsnprintf.h</a>) has been added. It
-provides snprintf and other string formatting routines.
-
-<h4>SILC Mutex Interface changes</h4>
-
-The SILC Mutex API (<a href="silcmutex.html">silcmutex.h</a>)
-has several changes. A support for read/write locks has been added
-(SilcRwLock). Also silc_mutex_assert_locked function is added.
-
-<h4>SILC Network Interface changes</h4>
-
-The SILC Network API
-(<a href="silcnet.html">silcnet.h</a>) has several changes. The API is almost
-entirely rewritten and most of the old functions have been removed. The
-API has now both TCP and UDP support, and as previously supports IPv4
-and IPv6. New functions are silc_net_tcp_create_listener,
-silc_net_listener_get_port, silc_net_close_listener, silc_net_tcp_connnect,
-silc_net_udp_connect, silc_net_udp_receive, silc_net_udp_send.
-
-<h4>SILC Scheduler Interface changes</h4>
-
-The SILC Schedule API
-(<a href="silcschedule.html">silcschedule.h</a>) has several changes. The
-scheduler has been entirely rewritten but most of the API remains the same.
-The SILC_TASK_GENERIC and SILC_TASK_CALLBACK_GLOCAL have been removed.
-The way signal are dispatched has been changed. The SILC Schedule is now
-able to itself dispatch all signals. New functions are
-silc_schedule_task_add_fd, silc_schedule_task_add_timeout,
-silc_schedule_task_add_signal, silc_task_del_by_all,
-silc_schedule_get_fd_events. The functions silc_schedule_signal_register,
-silc_schedule_signal_unregister and silc_schedule_signal_call have been
-removed.
-
-<h4>SILC Types Interface changes</h4>
-
-The SILC Type API (<a href="silctypes.html">silctypes.h</a>) has several
-changes. The bool type is replaced with SilcBool. Sockets are now
-represented by SilcSocket.
-
-<h4>SILC String util Interface changes</h4>
-
-The SILC string utility API
-(<a href="silcstrutil.html">silcstrutil.h</a>) has changes. The PEM encoding
-and decoding routines has been renamed, silc_base64_encode,
-silc_base64_encode_file and silc_base64_decode. The silc_mime_parse has
-been removed. A new silc_string_split function has been added.
-
-<h4>SILC Utility Interface changes</h4>
-
-
-<h4>SILC File Util Interface changes</h4>
-
-The SILC file utility API (<a href="silcfileutil.html">silcfileutil.h</a>)
-has changes. A new function silc_file_set_nonblock has been added.
-
-<h4>SILC List and Dynamic List Interface changes</h4>
-
-The SILC List (<a href="silclist.html">silclist.h</a>) and SILC Dynamic List
-(silcdlist.h) APIs have changes. New functions silc_list_insert and
-silc_dlist_insert have been added.
-
-<h4>SILC Buffer Interface changes</h4>
-
-The SILC Buffer API (<a href="silcbuffer.html">silcbuffer.h</a>) has several
-changes. The SilcBuffer
-structure no longer contain the buffer length and true length fields
-but silc_buffer_len() and silc_buffr_truelen() macros are available
-instead. Also silc_buffer_data(), silc_buffer_datalen(), silc_buffer_purge(),
-silc_buffer_reset(), silc_buffer_start(), silc_buffer_end() and
-silc_buffer_enlarge() has been added. The API also supports SilcStack.
-
-<h4>SILC Buffer Formatting Interface changes</h4>
-
-The SILC Buffer Formatting API
-(<a href="silcbuffmt.html">silcbuffmt.h</a>) has several changes. The
-silc_buffer_format now automatically allocates memory to the destination
-buffer if it does not have space. Also new the following new formatters
-have been added: SILC_STR_DATA (replaces SILC_STR_UI_XNSTRING),
-SILC_STR_BUFFER, SILC_STR_FUNC, SILC_STF_OFFSET and SILC_STR_ADVANCE.
-The API also supports SilcStack.
-
-<h4>SILC Memory Interface changes</h4>
-
-The memory allocation API (<a href="silcmemory.html">silcmemory.h</a>) has
-several changes. It supports now SilcStack as memory source. Also all
-memory allocation routines can now fail and return NULL as opposed to fatally
-failing when memory allocation fails.
-
-<br /> <br />
-<h3><a name="apputil"></a>SILC Application Utility library, lib/silcapputil/</h3>
-
-A new SILC Application Utility library has been added. It provides
-various application specific utility libraries that are not part of
-the runtime library (lib/silcutil/). The interfaces in the Application
-utility library were in other libraries in Toolkit 1.0 and the library
-does not contain any entirely new interfaces.
-
-<h4>SILC Application Utility Interface</h4>
-
-The <a href="silcapputil.html">silcapputil.h</a> contains various application
-utility functions. It
-existed in Toolkit 1.0 but some of the APIs has been changed. The
-silc_create_key_pair, silc_load_key_pair and silc_show_public_key APIs
-has changed. A new silc_show_public_key_file has been added. Functions
-silc_identifier_check, silc_identifier_verify, silc_channel_name_check,
-silc_channel_name_verify, silc_get_mode_list silc_get_status_message,
-silc_get_packet_name, silc_get_command_name, silc_parse_version_string,
-silc_version_to_num, silc_client_chmode, silc_client_chumode,
-silc_client_chumode_char and silc_id_render has been moved from other
-libraries into this interface in Toolkit 1.1.
-
-<h4>SILC ID Cache Interface</h4>
-
-The ID Cache interface (<a href="silcidcache.html">silcidcache.h</a>) has
-been moved from lib/silccore into lib/silcapputil/.
-
-<br /> <br />
-<h3><a name="skr"></a>SILC Key Repository library, lib/silcskr/</h3>
-
-A new SILC Key Repository library has been added. The library provides
-a SILC Key Repository API (<a href="silcskr.html">silcskr.h</a>) which provides
-a repository for storing and retrieving public keys.
-
-<br /> <br />
-<h3><a name="vcard"></a>SILC VCard library, lib/silcvcard/</h3>
-
-A new SILC VCard library has been added. The SILC VCard API has been
-moved from utility library to own library in lib/silcvcard/.
-
-<br /> <br />
-<h3><a name="http"></a>SILC HTTP library, lib/silchttp/</h3>
-
-A new SILC HTTP library has been added. The library includes SILC HTTP
-Server Interface and SILC HTTP PHP Translator Interface.
-
-<h4>SILC HTTP Server Interface</h4>
-
-The SILC HTTP Server API (<a href="silchttpserver.html">silchttpservder.h</a>)
-provides a simple HTTP server implementation for applications that want to
-integrate a small HTTP server.
-
-<h4>SILC HTTP PHP Translator Interface</h4>
-
-The SILC HTTP PHP Translator API (<a href="silchttpphp.html">silchttpphp.h</a>)
- provides PHP translates PHP code into HTML. It can be used to serve PHP
-pages in HTTP server.
-
-<br /> <br />
-<h3><a name="asn1"></a>SILC ASN.1 library, lib/silcasn1/</h3>
-
-A new Abstract Syntax Notation One (ASN.1) library has been added. The
-library provides SILC ASN.1 encoder and decoder interface and SILC BER
-encoder and decoder interface.
-
-<h4>SILC ASN.1 Interface</h4>
-
-The SILC ASN.1 API (<a href="silcasn1.html">silcasn1.h</a>) provides ASN.1
-encoder and decoder. The interface provides efficient encoder and decoder
-and is support SilcStack as memory source. The interface is simple and it
-supports almost all ASN.1 features.
-
-<h4>SILC BER Interface</h4>
-
-The SILC BER API (<a href="silcber.html">silcber.h</a>) provides BER/DER
-encoder and decoder. It is integral part of the ASN.1 library and the ASN.1
-encoder and decoder.
projects / runtime.git / commitdiff
