Re: [exim-dev] Standardizing the Exim documentation

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Nigel Metheringham
Date:  
À: Nico Erfurth
CC: exim-dev
Sujet: Re: [exim-dev] Standardizing the Exim documentation
On Thu, 2004-11-04 at 14:18 +0100, Nico Erfurth wrote:
> Nigel Metheringham wrote:
>
> > However I could well be convinced at present to stay with SGCAL format
> > and write stuff to spit out docbook/xml or some other good intermediate
> > format.
>
> The question is, how does SGCAL look like? Is it really that complex?


Looks like something between RUNOFF/RUNOFQ (which is where I started
out) and troff to me.

I've put a shortish chunk in following on from the next line. Lines may
have additionally wrapped.

    Nigel.


.section Message identification
.rset SECTmessiden "~~chapter.~~section"
.index message||ids, details of format
.index format||of message id
.index id of message
.index base62
.index base36
.index Darwin
.index Cygwin
Every message handled by Exim is given a \*message id*\ which is sixteen
characters long. It is divided into three parts, separated by hyphens, for
example \"16VDhn-0001bo-D3"\. Each part is a sequence of letters and digits,
normally encoding numbers in base 62. However, in the Darwin operating
system (Mac OS X) and when Exim is compiled to run under Cygwin, base 36
(avoiding the use of lower case letters) is used instead, because the message
id is used to construct file names, and the names of files in those systems are
not case-sensitive.

.index pid (process id)||re-use of
The detail of the contents of the message id have changed as Exim has evolved.
Earlier versions relied on the operating system not re-using a process id (pid)
within one second. On modern operating systems, this assumption can no longer
be made, so the algorithm had to be changed. To retain backward compatibility,
the format of the message id was retained, which is why the following rules are
somewhat eccentric:
.numberpars $.
The first six characters of the message id are the time at which the message
started to be received, to a granularity of one second. That is, this field
contains the number of seconds since the start of the epoch (the normal Unix
way of representing the date and time of day).
.nextp
After the first hyphen, the next six characters are the id of the process that
received the message.



-- 
[ Nigel Metheringham           Nigel.Metheringham@??? ]
[ - Comments in this message are my own and not ITO opinion/policy - ]