summaryrefslogtreecommitdiffstats
path: root/kpilot/Documentation/HOWTO-CONDUIT.txt
diff options
context:
space:
mode:
Diffstat (limited to 'kpilot/Documentation/HOWTO-CONDUIT.txt')
-rw-r--r--kpilot/Documentation/HOWTO-CONDUIT.txt67
1 files changed, 0 insertions, 67 deletions
diff --git a/kpilot/Documentation/HOWTO-CONDUIT.txt b/kpilot/Documentation/HOWTO-CONDUIT.txt
deleted file mode 100644
index 7b6dccd0b..000000000
--- a/kpilot/Documentation/HOWTO-CONDUIT.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-One of the greatest assets of the Palm Pilot is its ability to
-interconnect with other applications. KPilot supports this capabilty
-through conduits. A conduit is a small shared library that is loaded by
-the daemon during the hot sync. The conduit translates between the Palm
-Pilot and the application you're syncing with.
-
-*** How it works
-
-KPilot is divided into three major components: the GUI, the
-syncing daemon, and the conduits. The GUI part is actually irrelevant
-for the operation of the daemon, although it _is_ required for the
-configuration dialog (and possibly viewing databases). In theory
-you could run the daemon on a box without even starting X, although
-that is difficult (in particular, how would you do conflict resolution?).
-
-The daemon sits around and polls the configured device every second or
-so (there are devices where this should be more often, I think). Once
-data arrives (and the device exists, consider hotplug with USB), the
-daemon enters sync mode, and constructs a queue of SyncActions to perform.
-These vary from checking the Pilot's username to performing full backups
-to -- whatever sync actions the conduits provide. This means that during
-a sync the shared library containing a conduit is loaded, a factory
-function is called to produce an Action, this action is run, and the
-library unloaded.
-
-*** How the conduits work
-
-The conduits can actually be divided into two parts: the configuration
-widget, and the Action. Both are produced by a factory function in
-the shared library. The conduits have only one really interesting method
-that they must override, and that is exec(). When this is called the
-conduit is already set up with a socket descriptor and the conduit should
-quickly do its thing. In particular, conduits can't just sleep(45) and
-continue, since the connection with the Pilot will time out.
-
-*** Write your very own conduit
-
-Writing a conduit is actually rather easy. The conduit class
-should inherit from ConduitAction and override the exec() method
-(which actually comes from SyncAction).
-
-
-*** Debugging things
-
-lib/options.h contains two defines that are really important for
-debugging. These are
-
- // #define DEBUG (1)
- // #define DEBUG_CERR (1)
-
-Uncommenting DEBUG will enable most of the debug information in
-KPilot. Uncommenting DEBUG_CERR will make debug output go direct
-to stderr (cerr) instead of through kdDebug. If in addition, you
-pass --debug N (say, N=1 or N=4) to KPilot or the daemon when you
-start them, they will print call traces (that's what FUNCTIONSETUP
-does, which you will see at the beginning of every function).
-
-Another useful tool is kpilotTest, which is in kpilot/kpilot. It
-is an uninstalled binary, which behaves like the daemon with a
-log window and which will run a single conduit. Something like:
-
- kpilotTest -p /dev/ucom0 \ # port
- -E conduit_knotes \ # .desktop file
- -T # _really_ run
-
-use kpilotTest -L to list the installed conduits and their
-desktop files (look at the "In ..." lines).