@ -16,7 +16,7 @@
<author>
<firstname>Bernd</firstname>
<surname>Gehrmann</surname>
<affiliation><address><email>bernd@t develop.org</email></address></affiliation>
<affiliation><address><email>bernd@k develop.org</email></address></affiliation>
</author>
</authorgroup>
@ -71,9 +71,9 @@ respecting user preferences.
</varlistentry>
<varlistentry>
<term><ulink url="kdeapi:tdeio/index.html">k io</ulink></term>
<term><ulink url="kdeapi:tdeio/index.html">tde io</ulink></term>
<listitem><para>
The <literal>k io</literal> library contains facilities for asynchronous,
The <literal>tde io</literal> library contains facilities for asynchronous,
network transparent I/O and access to mimetype handling. It also provides the
KDE file dialog and its helper classes.
</para></listitem>
@ -2074,7 +2074,7 @@ needed. It then goes into a loop and listens for DCOP connections. The program
may be an interactive one, but it may also run completely or for a part of its
lifetime as a daemon in the background without the user noticing it. An example
for such a daemon is <literal>tdeio_uiserver</literal>, which implements user interaction
such as progress dialog for the K IO library. The advantage of such a centralized
such as progress dialog for the TDE IO library. The advantage of such a centralized
daemon in this context is that e.g. the download progress for several different
files can be shown in one window, even if those downloads were initiated from
different applications.
@ -2393,7 +2393,7 @@ else
</programlisting>
<para>
This starts a K IO job to download a part of the file and check this.
This starts a TDE IO job to download a part of the file and check this.
Note that this function is perhaps quite slow and blocks the program. Normally
you will only want to use this if <function>KMimeType::findByURL()</function>
has returned <literal>"application/octet-stream"</literal>.
@ -2401,7 +2401,7 @@ has returned <literal>"application/octet-stream"</literal>.
<para>
On the other hand, if you do not want to block your application, you can also
explicitly start the K IO job and connect to some of its signals:
explicitly start the TDE IO job and connect to some of its signals:
</para>
<programlisting>
@ -2558,7 +2558,7 @@ completely available, but should updated regularly as data comes in.
</para>
<para>
In the KDE libraries, network transparency is implemented in the K IO API. The
In the KDE libraries, network transparency is implemented in the TDE IO API. The
central concept of this architecture is an IO <emphasis>job</emphasis>. A job
may copy, or delete files or similar things. Once a job is started, it works
in the background and does not block the application. Any communication from
@ -2589,10 +2589,10 @@ http://www-com.physik.hu-berlin.de/~bernd/article.tgz#tar:/paper.tex
<simplesect id="nettransparency-usingkio">
<title>Using K IO</title>
<title>Using TDE IO</title>
<para>
In most cases, jobs are created by calling functions in the K IO namespace.
In most cases, jobs are created by calling functions in the TDE IO namespace.
These functions take one or two URLs as arguments, and possible other
necessary parameters. When the job is finished, it emits the signal
<literal>result(TDEIO::Job*)</literal>. After this signal has been emitted, the job
@ -2855,7 +2855,7 @@ easier to use: the class <classname>KFileItem</classname>.
<title>Synchronous usage</title>
<para>
Often, the asynchronous API of K IO is too complex to use and therefore
Often, the asynchronous API of TDE IO is too complex to use and therefore
implementing full asynchronicity is not a priority. For example, in a program
that can only handle one document file at a time, there is little that can be
done while the program is downloading a file anyway. For these simple cases,
@ -2965,7 +2965,7 @@ void FooClass::transferResult(TDEIO::Job *job)
<title>Scheduling</title>
<para>
When using the K IO API, you usually do not have to cope with the details of
When using the TDE IO API, you usually do not have to cope with the details of
starting IO slaves and communicating with them. The normal use case is to
start a job and with some parameters and handle the signals the jobs emits.
</para>
@ -2973,7 +2973,7 @@ start a job and with some parameters and handle the signals the jobs emits.
<para>
Behind the curtains, the scenario is a lot more complicated. When you create a
job, it is put in a queue. When the application goes back to the event loop,
K IO allocates slave processes for the jobs in the queue. For the first jobs
TDE IO allocates slave processes for the jobs in the queue. For the first jobs
started, this is trivial: an IO slave for the appropriate protocol is started.
However, after the job (like a download from an http server) has finished, it
is not immediately killed. Instead, it is put in a pool of idle slaves and
@ -2988,7 +2988,7 @@ Of course, reusing is only possible when the existing slave has already finished
its previous job. when a new request arrives while an existing slave process is
still running, a new process must be started and used. In the API usage in the
examples above, there are no limitation for creating new slave processes: if you
start a consecutive series of downloads for 20 different files, then K IO will
start a consecutive series of downloads for 20 different files, then TDE IO will
start 20 slave processes. This scheme of assigning slaves to jobs is called
<emphasis>direct</emphasis>. It not always the most appropriate scheme, as it
may need much memory and put a high load on both the client and server machines.
@ -3093,14 +3093,14 @@ The "input" and "output" lines are not used currently.
<para>
The remaining lines in the <literal>.protocol</literal> file define which
abilities the slave has. In general, the features a slave must implement are
much simpler than the features the K IO API provides for the application. The
much simpler than the features the TDE IO API provides for the application. The
reason for this is that complex jobs are scheduled to a couple of subjobs. For
example, in order to list a directory recursively, one job will be started for
the toplevel directory. Then for each subdirectory reported back, new subjobs
are started. A scheduler in K IO makes sure that not too many jobs are active
are started. A scheduler in TDE IO makes sure that not too many jobs are active
at the same time. Similarly, in order to copy a file within a protocol that
does not support copying directly (like the <literal>ftp:</literal> protocol),
K IO can read the source file and then write the data to the destination
TDE IO can read the source file and then write the data to the destination
file. For this to work, the <literal>.protocol</literal> must advertise the
actions its slave supports.
</para>
@ -3174,7 +3174,7 @@ functions:
<para>
Additionally, there are reimplementable functions not listed in the <literal>.protocol</literal>
file. For these operations, K IO automatically determines whether they are supported
file. For these operations, TDE IO automatically determines whether they are supported
or not (i.e. the default implementation returns an error).
</para>