replication_protocol.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Cyrus IMAP Server: Replication Protocol v2.4+</title>
</head>
<body>

<h1>Cyrus IMAP Server: Replication Protocol v2.4+</h1>

<h2>DList 1.0</h2>

<p>The DList protocol is based closely on the IMAP wire protocol,
using atoms and literals as the basis, but with two extended types
of data:</p>

<ul>
<li>kvlist</li>
<li>rfc822-object</li>
</ul>

A wart of the protocol is the rfc822-object, which contains an
explicit cyrus backend partition.  This will be removed in future
versions of Cyrus.

<h3>types</h3>

<h4>atom</h4>

<p>An atom is actually a sequence of any character other than '\0',
the NULL byte.  Character encoding is not specified, but it can
contain 8 bit characters, and is probably utf8</p>

<h4>flag</h4>

<p>Flag is a horrible special case of atom to allow \word to be
represented as an IMAP atom on the wire.  This is one of many
special cases in the IMAP protocol, and is duplicated into dlist
just to make it easier to read</p>

<h4>num32/num</h4>

<p>Both stored as 64 bit integers internally, and sent as decimal
numbers over the wire, this type exists only in the API, it just
looks like a string on the wire.</p>

<h4>hex32/hex</h4>

<p>Stored like num internally, but sent as an 8 or 16 character
hexadecimal string on the wire</p>

<h4>map</h4>

<p>Like atom, but can contain NULL.  All values are parsed off
the wire as 'map' type and then converted on demand into the
requested type</p>

<h4>list</h4>

<p>Encoded in parentheses like so (item item item) a list type can
be nested inside other lists: (item (sub sub) item)</p>

<h4>kvlist</h4>

<p>A kvlist allows named parameters, and is indicated with a leading
% character.  % is invalid in atoms, so parsing is unambiguous, e.g:</p>

<p>%(key1 value1 key2 (list of values) key3 value3)</p>

<h4>rfc822-object/file</h4>

<p>Finally the ugly one.  These look like a literal, but with a leading %
and two more fields:</p>

<pre>
%{partition sha1 size}\r\n
data
</pre>

</body>
</html>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<title>Cyrus IMAP Server: Replication Protocol v2.4+</title>
	</head>
	<body>

	<h1>Cyrus IMAP Server: Replication Protocol v2.4+</h1>

	<h2>DList 1.0</h2>

	<p>The DList protocol is based closely on the IMAP wire protocol,
	using atoms and literals as the basis, but with two extended types
	of data:</p>

	<ul>
	<li>kvlist</li>
	<li>rfc822-object</li>
	</ul>

	A wart of the protocol is the rfc822-object, which contains an
	explicit cyrus backend partition. This will be removed in future
	versions of Cyrus.

	<h3>types</h3>

	<h4>atom</h4>

	<p>An atom is actually a sequence of any character other than '\0',
	the NULL byte. Character encoding is not specified, but it can
	contain 8 bit characters, and is probably utf8</p>

	<h4>flag</h4>

	<p>Flag is a horrible special case of atom to allow \word to be
	represented as an IMAP atom on the wire. This is one of many
	special cases in the IMAP protocol, and is duplicated into dlist
	just to make it easier to read</p>

	<h4>num32/num</h4>

	<p>Both stored as 64 bit integers internally, and sent as decimal
	numbers over the wire, this type exists only in the API, it just
	looks like a string on the wire.</p>

	<h4>hex32/hex</h4>

	<p>Stored like num internally, but sent as an 8 or 16 character
	hexadecimal string on the wire</p>

	<h4>map</h4>

	<p>Like atom, but can contain NULL. All values are parsed off
	the wire as 'map' type and then converted on demand into the
	requested type</p>

	<h4>list</h4>

	<p>Encoded in parentheses like so (item item item) a list type can
	be nested inside other lists: (item (sub sub) item)</p>

	<h4>kvlist</h4>

	<p>A kvlist allows named parameters, and is indicated with a leading
	% character. % is invalid in atoms, so parsing is unambiguous, e.g:</p>

	<p>%(key1 value1 key2 (list of values) key3 value3)</p>

	<h4>rfc822-object/file</h4>

	<p>Finally the ugly one. These look like a literal, but with a leading %
	and two more fields:</p>

	<pre>
	%{partition sha1 size}\r\n
	data
	</pre>

	</body>
	</html>