# sample.coldsyncrc
#
# $Id: sample.coldsync.rc,v 1.10 2002/11/13 12:10:20 azummo Exp $
#
# This is an example .coldsyncrc file. It is NOT intended as a working
# configuration. It is rather a series of examples. Read it through.
# At least glance at it. Then read the manual.

########################################
### Options block
########################################
# You may specify global options and variables here if you wish.
# Useful options are:
# CS_CONDUITDIR: a colon separated list of directories, in which conduits may
#             be found.
# CS_LOGFILE:  the log file where information is printed. (If none is specified,
#           logs go to stdandard error.)
options {
	CS_CONDUITDIR: "$(CS_CONDUITDIR):$(HOME)/.palm/conduits";
}
########################################
### Listen block
########################################

# Your .coldsyncrc should begin with a listen block. This tells
# ColdSync which device to listen to, at what speed the sync will
# place, and so forth.
# If you omit the listen block, ColdSync will substitute defaults. The
# following listen block is equivalent to the defaults:

listen serial {
	device: "/dev/palm";
	speed: 38400;
}

# OR, if you're using a modem with mgetty, disable the above listen block
# and insert this one.
# 
# listen serial "mgetty" {
#	device: stdin;
#	nochangespeed;
# }


# USB: See README.usb for details.

# If you're syncing your PDA over USB under FreeBSD, use "usb" instead
# of "serial":

listen usb "usb-bsd" {
	device: "/dev/ugen0";
}

# However, if you're syncing under Linux, and using the "make
# the USB bus look like a serial device" hack, also known
# as "the visor kernel module", you should use "serial"
# anyway:

# NOTE: You need to use "protocol: full;" for some Visor units.

listen serial "usb-linux" {
	protocol: net;
	device: /dev/ttyUSB1;
}

#  or, if you use devfs,

listen serial "usb-linux-devfs" {
	protocol: net;
	device: /dev/usb/tts/1;
	transient;
}

# NetSync: See README.daemon for details.

# If you'd like to experiment with network hotsync, the following
# two blocks are for you:

listen serial "netsync-inetd" {
	protocol: net;
	device: stdin;
	noprompt;
}

listen net "netsync-standalone"
{
}

########################################
### PDA block
########################################

# If you have more than one Palm, you can sync them to different
# directories by declaring PDA blocks. Specify the Palm's serial
# number using the "snum" directive, and the directory to sync with
# using the "directory" directive:

pda "My Palm III" {
	snum: "189X7M27GA63-N";
	directory: "/home/arensb/.palmIII";
}

# If your Palm doesn't have a serial number in ROM (e.g., a PalmPilot
# or Visor), use the empty string (of course, if you have more than
# one such Palm, they'll all use the same PDA block):

pda "My PalmPilot Pro" {
	snum: "";
	directory: "/home/arensb/.palmPilot";
}

# The 'default' keyword specifies that this PDA block should be used
# if no others match. In the following example, the backup directory
# for the Palm III will be /home/arensb/.palmIII; the backup directory
# for old Palms with no serial number will be /home/arensb/.palmPilot;
# and the backup directory for anything else will be
# /home/arensb/.allPalms .

pda "My Palm III" {
	snum: "189X7M27GA63-N";
	directory: "/home/arensb/.palmIII";
}

pda "Default for old PalmPilots" {
	snum: "";
	directory: "/home/arensb/.palmPilot";
	default;
}

pda "Default for everything else" {
	directory: "/home/arensb/.allPalms";
	default;
}

########################################
### Conduits
########################################

# Conduits presently come in three flavors: Fetch, Dump, and Sync.
#
# Fetch conduits are run before the main sync. They are intended to
# gather data from files and create or update the databases with which
# ColdSync will then sync.
#
# Dump conduits run after the main sync. They are intended to convert
# the newly-synchronized databases back into whatever form is most
# useful on the local machine.
#
# Sync conduits run during the main portion of the sync, and can run
# instead of, or in addition to the built-in generic conduit. They are
# intended for cases too complex to be easily handled by Fetch and
# Dump conduits.
#
# Other than that, conduits run in the order in which they appear in
# the .coldsyncrc

## Example 0:
# If you do not have a .coldsyncrc file, the following is equivalent
# to the defaults. It says to run the built-in generic conduit on all
# databases unless another one has been specified.

conduit sync {
	path: [generic];
	type: */*;
	default;
}

## Example 1:
# 'memo-text', when run as a Fetch conduit, converts the file
# /home/arensb/Memos into a .pdb file; when run as a Dump conduit, it
# converts the .pdb file back into text format in /home/arensb/Memos.

conduit fetch, dump {
	path: "/usr/local/libexec/conduits/memo-text";
	type: memo/DATA;
    arguments:
	File:	/home/arensb/Memos;
	Delete: no;
}

## Example 2:
# ColdSync processes databases in apparently-random order. For each
# database, however, conduits are run in the order in which they
# appear in the .coldsyncrc . Here, "conduit1" will always run before
# "conduit2".

conduit fetch {
	path: "/usr/local/libexec/conduits/conduit1";
	type: memo/DATA;
}

conduit fetch {
	path: "/usr/local/libexec/conduits/conduit2";
	type: memo/DATA;
}

## Example 3:
# The 'default' keyword specifies that a conduit will be run if no
# more suitable conduit can be found. In the following example,
# 'default-conduit' is a default for all databases.
#
# When ColdSync runs the Fetch conduits for the Memo application, it
# will run 'memo-text', but will not run 'default-conduit' because a
# better match has been found.
# When ColdSync runs the Fetch conduits for the Address Book
# application, it will only run 'default-conduit' because no other
# conduit matches.

conduit fetch {
	path: "/usr/local/libexec/conduits/default-conduit";
	type: */*;
	default;
}

conduit fetch {
	path: "/usr/local/libexec/conduits/memo-text";
	type: memo/DATA;
}

## Example 4:
# It is possible to specify several default conduits. Only the last
# matching conduit will be run, however.
#
# In this example, ColdSync will run 'default-todo' for all databases
# whose creator is "todo" (and will not run 'default-conduit'). It
# will run 'default-conduit' for all other databases.

conduit fetch {
	path: "/usr/local/libexec/conduits/default-conduit";
	type: */*;
	default;
}

conduit fetch {
	path: "/usr/local/libexec/conduits/default-todo";
	type: todo/*;
	default;
}

## Example 5:
# The 'final' keyword indicates that no other conduits should be
# considered.
# In the following example, 'conduit1' and 'conduit2' will be run, but
# 'conduit3' will never be run.

conduit dump {
	path: "/usr/local/libexec/conduits/conduit1";
	type: todo/DATA;
}

conduit dump {
	path: "/usr/local/libexec/conduits/conduit2";
	type: todo/DATA;
	final;
}

conduit dump {
	path: "/usr/local/libexec/conduits/conduit3";
	type: todo/DATA;
}

## Example 6:
# If a conduit block does not contain a 'path' statement, it is
# effectively a "do-nothing" conduit. This is mainly useful for the
# side effects if you want to declare it as 'final'.
#
# In the following example, 'conduit2' will never be run, for any
# database:

conduit dump {
	path: "/usr/local/libexec/conduits/conduit1";
	type: todo/DATA;
}

conduit dump {
	type: */*;	# Applies to all databases
	final;
}

conduit dump {
	path: "/usr/local/libexec/conduits/conduit2";
	type: todo/DATA;
}

## Example 7:
# A conduit also has access to preferences; these are bits of
# configuration data that aren't stored in the database being synced.
# Each conduit's documentation should say which preferences it is
# interested in.

conduit sync {
        path: "/usr/local/libexec/conduits/deliver-mail";
        type: mail/DATA;
        pref: mail/3;		# Mail signature preference
}