← Back to branch summary

~ubuntu-branches/ubuntu/quantal/dovecot/quantal

« back to all changes in this revision

Viewing changes to sieve/doc/devel/DESIGN

  • Committer: Bazaar Package Importer
  • Author(s): Chuck Short
  • Date: 2010-06-29 09:21:32 UTC
  • mfrom: (4.1.14 sid)
  • Revision ID: james.westby@ubuntu.com-20100629092132-q4pr5lfuvmjqou19
Tags: 1:1.2.12-1ubuntu1
https://launchpad.net/bugs/597818
* Merge from Debian Unstable, remaining changes:
  + Add mail-stack-delivery as per server-maverick-mail-integration spec:
   - Update debian/rules
   - Convert existing package to a dummy package and add new binary in debian/control
   - Update maintainer scripts.
   - Move previously installed backups and config files to new package name
     space in preinst
   - Add new debian/mail-stack-delivery.prerm to handle downgrades
   - Rename debian/dovecot-postfix.* to debian/mail-stack-delivery.*
  + Use Snakeoil SSL certificates by default.
    - debian/control: Depend on ssl-cert.
    - debian/patches/ssl-cert-snakeoil.dpatch: Change default SSL cert paths to snakeoil.
    - debian/dovecot-common.postinst: Relax grep for SSL_* a bit.
  + Add autopkgtest to debian/tests/*.
  + Add ufw integration:
    - Created debian/dovecot-common.ufw.profile.
    - debian/rules: install profile.
    - debian/control: suggest ufw.
  + debian/{control,rules}: enable PIE hardening.
  + debian/control: Update Vcs-* headers.
  + Add SMTP-AUTH support for Outlook (login auth mechanism) 
  + debian/dovecot-common.dirs: Added usr/share/doc/dovecot-common
  + debian/patches/fix-dovecot-config-parser.patch: Fix ordering of external config 
    files. (LP: #597818)

Show diffs side-by-side

added added

removed removed

Lines of Context:
sieve/doc/devel/DESIGN
1
1
The compiler consists of the following stages:
2
2
 
3
3
PARSER: sieve-parser.c, sieve-lexer.c
4
 
  Parses the scriptfile and produces an abstract syntax tree for it 
5
 
  (sieve-ast.c). 
 
4
  Parses the scriptfile and produces an abstract syntax tree for it
 
5
  (sieve-ast.c).
6
6
 
7
7
VALIDATOR: sieve-validator.c
8
 
  Performs contextual analysis on the ast produced by the parser. This checks 
9
 
  for the validity of commands, tests and arguments. Also, the ast is decorated 
10
 
  with any context data acquired during the process. This context is used by the 
11
 
  last compiler stage. 
 
8
  Performs contextual analysis on the ast produced by the parser. This checks
 
9
  for the validity of commands, tests and arguments. Also, the ast is decorated
 
10
  with any context data acquired during the process. This context is used by the
 
11
  last compiler stage.
12
12
 
13
13
GENERATOR: sieve-generator.c
14
 
  This last compiler stage uses a visitor pattern to wander through the ast and 
 
14
  This last compiler stage uses a visitor pattern to wander through the ast and
15
15
  produces sieve byte code (sieve-binary.c).
16
16
 
17
17
The resulting (in-memory) binary can be fed to the interpreter for execution:
18
18
 
19
 
INTERPRETER: sieve-interpreter.c 
20
 
  The interpreter executes the byte code and produces a sieve_result object. 
21
 
  This result is no more than just a collection of actions to be performed. 
22
 
  During execution, action commands add actions to the result. Duplates and 
 
19
INTERPRETER: sieve-interpreter.c
 
20
  The interpreter executes the byte code and produces a sieve_result object.
 
21
  This result is no more than just a collection of actions to be performed.
 
22
  During execution, action commands add actions to the result. Duplates and
23
23
  conflicts between actions are handled in this execution phase.
24
24
 
25
25
RESULT: sieve-result.c sieve-actions.c
26
 
  When the result is to be executed, it needs no further checking, as the 
27
 
  validity of the result was verified during interpretation already. The 
28
 
  result's actions are executed in a transaction-like atomic manner. If one of 
29
 
  the actions fails, the whole transaction is rolled back meaning that either 
 
26
  When the result is to be executed, it needs no further checking, as the
 
27
  validity of the result was verified during interpretation already. The
 
28
  result's actions are executed in a transaction-like atomic manner. If one of
 
29
  the actions fails, the whole transaction is rolled back meaning that either
30
30
  everything succeeds or everything fails. This is only possible to some extent:
31
 
  transmitted responses can of course not be rolled back. However, these are 
 
31
  transmitted responses can of course not be rolled back. However, these are
32
32
  executed in the commit phase, meaning that they will only be performed if all
33
33
  other actions were successful.
34
 
  
 
34
 
35
35
Debugging:
36
36
 
37
37
BINARY-DUMPER: sieve-code-dumper.c sieve-binary-dumper.c
38
 
  A loaded binary can be dumped to a stream in human-readable form using the 
 
38
  A loaded binary can be dumped to a stream in human-readable form using the
39
39
  binary-dumper. The binary-dumper displays information on all the blocks that
40
40
  the binary consists off. Program code blocks are dumped using the code-dumper.
41
 
  It's implementation is similar to the interpreter, with the exception that it 
42
 
  performs no actions and just sequentially wanders through the byte code 
43
 
  printing instructions along the way. The term human-readable is a bit optimistic 
44
 
  though; currently, the presented data looks like an assembly language. 
 
41
  It's implementation is similar to the interpreter, with the exception that it
 
42
  performs no actions and just sequentially wanders through the byte code
 
43
  printing instructions along the way. The term human-readable is a bit optimistic
 
44
  though; currently, the presented data looks like an assembly language.
45
45