"Fossies" - the Fresh Open Source Software Archive

Member "tin-2.4.1/doc/art_handling.txt" (28 Aug 2013, 2618 Bytes) of package /linux/misc/tin-2.4.1.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 Basic API
    2 ---------
    3 An article is opened with art_open() and closed with art_close()
    4 There is no side-effect, all I/O is done via a t_openartinfo.
    5 art_close() is not implied anywhere - you must call it when you need to.
    6 
    7 t_openartinfo
    8 -------------
    9 This is basically an 'open article context'. You can pass these around or do
   10 anything with them independently of the rest of the program.
   11 
   12 This structure contains open file pointers, one to the raw article,
   13 the other to the cooked article. There is no file related to these streams.
   14 If you close them, the data is lost.
   15 
   16 Each stream has a summary array of type t_lineinfo which is an array of
   17 line offsets and 'hint' flags associated with that line.
   18 The array for the raw stream is built on demand since most of the time it
   19 is not needed.
   20 The flags are used for speedy access to parts of the article as well as
   21 information about interesting things on that line.
   22 
   23 The cooked stream lineinfo is of size 'cooked_lines' which is found in
   24 the t_openartinfo structure. The size of the raw stream is stored in
   25 the article structure information attached to the header.
   26 
   27 The header contains all the useful information about the article & its
   28 structure.
   29 
   30 t_header
   31 --------
   32 This builds upon the header structure in tin-1.4
   33 The main structure consists of pointers to the regular RFC822 headers
   34 
   35 Every article has a pointer to an 'ext' structure (of type t_part) which holds
   36 extended header information.
   37 
   38 If there are attachments, then the ext structure is the head of a linked
   39 list of attachments.
   40 
   41 t_part
   42 ------
   43 There is one of these per article 'part' or attachment. The article as a
   44 whole counts as 1 part so there will always be at least one of these structures
   45 linked to the header.
   46 Each t_part is pre-initialised to the RFC2045 defaults. (text/plain, 7bit etc..)
   47 Content-* headers if present will then supersede this information.
   48 The other fields are:
   49 params		A linked list of parameters associated with the Content-Type and
   50 			Content-Disposition headers
   51 offset		The byte offset of this attachment. The offset of header->ext is
   52 			the offset of the 822 body
   53 lines		The number of lines of raw text in this attachment. The number of
   54 			lines in header->ext is the total number of lines in the article
   55 			body
   56 uue			A linked list of uuencoded sections found in the current t_part
   57 			The uue filename is found in a parameter called 'name'
   58 
   59 
   60 
   61 The code tries to conform to the following RFC's
   62 
   63 1806 - Content-Disposition header
   64 2045 - MIME article extensions to RFC822
   65 2046 - Content-Type, multipart article structure
   66 2047 - MIME encodings (most of the code still refers to 1522)