1 files changed, 64 insertions, 0 deletions
diff --git a/doc/artsbuilder/porting.docbook b/doc/artsbuilder/porting.docbook
new file mode 100644
index 00000000..f039904e
--- /dev/null
+++ b/doc/artsbuilder/porting.docbook
@@ -0,0 +1,64 @@
+<!-- <?xml version="1.0" ?>
+<!DOCTYPE chapter PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd">
+To validate or process this file as a standalone document, uncomment
+this prolog. Be sure to comment it out again when you are done -->
+
+<chapter id="porting">
+<title>Porting Applications to &arts;</title>
+
+<sect1 id="using-artsdsp">
+<title>Using &artsdsp;</title>
+
+<para>
+The &artsdsp; utility, <link linkend="artsdsp">described
+previously</link>, allows most legacy sound applications that talk to
+the audio devices directly, to work properly under &arts;. Applications
+written to use the Enlightenment Sound Daemon
+(<application>esd</application>) will also work in most cases by running
+<application>esd</application> under &artsdsp;.
+</para>
+
+<para>
+This makes a good short term solution to porting existing applications
+to &kde;. However, it does not allow the application to directly take
+advantage of all of the power of &arts;, such as using modules and
+multimedia streams other than digital audio. If the application goes
+beyond simple playing of sound files, it usually makes sense to add
+native support for &arts; to the application.
+</para>
+
+<para>
+Using &arts; also means that application does not have to do as much
+work -- it can leverage the functions in &arts; to handle issues like
+codecs for different media formats and control of the sound hardware.
+</para>
+
+</sect1>
+
+<sect1 id="adding-native-arts-support">
+<title>Adding Native &arts; support</title>
+
+<para>
+When using &arts;, you have a number of different <link
+linkend="arts-apis"><acronym>API</acronym>s</link> to choose from. The
+decision of which to use depends on a number of factors, including what
+type of streaming media is used (sound, &MIDI;, &CD; audio, &etc;), the
+<acronym>API</acronym> features required, and whether it is written in
+C++. In most cases the choice should be relatively obvious based on the
+required features.
+</para>
+
+<para>
+For cross-platform portability, applications that need to run on
+environments other than &kde; cannot rely on &arts; being present. Using
+the plug-ins paradigm is a good way to support different multimedia
+environments. Making the plug-in <acronym>API</acronym> open and
+documented (especially for closed source applications) also has the
+advantage of allowing someone other than the application developer to
+implement an &arts; plug-in.
+</para>
+
+</sect1>
+
+</chapter>
+