Design document for nitpo * envelope address It can be sent set manually by using the 'ENVELOPE_ADDRESS' in the headers xslt file. Failing that, it can be set by ['addresses']['envelope'] * * admin and volun There are two types of s * orimas The orima of a report is the address of the selector who maintains it. Clearn * action An action is a way to use the nitpo software. The major basic action is "repis". It is for sending report issues, called repis. A repis is defined by a report, and a date of the issue of that report. The other actions are minor actions. The "selan" action is to communicate to selectors. In that action, each selector gets an email based on the data of the report. Since a selector may have various reports, it is important that all the reports that a selector has a captured in each instance of a report description data. A selin is characterized by a date. The "brore" action is a broadcast to all readers. Each reader's profile is used to send the message. A brore is characterized by a date. Brores are not send to omnibus readers. The "rebro" is a broadcast to all readers of a report. For a rebro, we take the file that describes the report, and inject the subscription profile. A brore is characterized by a report code and a date. The selan The selan needs to combine all reports by an address. This is done by appliyng the orima.xslt.xml file in the xslt directory to each file in the reports directory. The element is used to wrap all the files that have the same emad. When performaing a selin, we need to find data on the reports. These are assumig This is the new items poster. Nitpo runs in the directory of a non-privileged user. This is the nitposer. Its ~/etc/nipos.ini is the Microsoft init file-like configuration used. That location is fixed. All others are set in it that file. Setting [folders][repis] has the report issues (repis) directory. This has subfolders per issue dates yyyy-mm-dd. We have no support for several issues in a day. There the files of the former repcode.xml[.gz] contain the report issue of the report identified by repcode. It follows that repcodes cannot contain slashes. The file system is supposed to use UTF-8 encoded names. Others are unsupported. Nitpo does not write to the repis folder. It reads from it. Since timing is critical, nitpo does not use file modification times. Instead, it orders files by string comparison. There are two parameters that guide the reading of the input. First, there is [names][repisep]. This is a character separates the repcode from the indicator of priority. Then, there is [names][repisext] which has the extension, minus the .gz that would indicate compression. Thus is repisep is ‘_’ and the repisext is .amf.xml, the file foo_bar.amf.xml.gz would be the issue file for repcode “foo”. It would be considered at at a priority “bar”. That is, say bar_foo.amf.xml.gz would be considered to have priority over foo_bar.amf.xml. That means that subscribers of report foo and bar would not be sent items that has been appreaing in report foo, because bar came out later, or more generally at a lower priority than foo. Setting [folders][profiles] has the profiles directory. This contains the subscriptions per email address (emad). For a given emad, reverse the dot-separated domain components. Remove the @ and use the user name as the base name of the file. Example: krichel@openlib.org --> org/openlib/krichel.xml. The profile data follows the relax-ng spec in etc/profile.rng.xml. In addition, the element can not contains two subscriptions with the same repcode attribute. A profile that has no argument or that only has an empty element is saved as a .xml.gz to speed up processing. In transition from mailman, profiles are derived data build from historic data and incrementally changed by inspection of mailman logs. Setting [folders][reports] has the reports directory. The recode of a report will be the part of the file name before the [ext][report] configured report extension, followed by optional .gz. Setting [files][instance] has . A destin is different from a profile. It is maintained as a file repcode.xml. Here, we store the information about each report. The destin xml of a report is inserted in the source document of every repis of that report. Setting [repis][to_orima] to '1', 'yes', 'true', or 'on', will send report issues to the orima. Setting it to '0', 'no', 'false', and 'off' will not send it. This is the default. Setting [repis][to_omnibus] to '1', 'yes', 'true', or 'on', will send report issues to the omnibus. Setting it to '0', 'no', 'false', and 'off' will not send it. This is the default. Each repis comes from a person called a reporter. The reporter has an emad that is ought to be given in the reply-to header of the repis email. The reporter should get a copy of the report email. There as a question as to what status that emad has. Nitpo has no way of knowing what the emad is. Now the emad could be * glossary emad the email address just as the address like “krichel@openlib.org”. emad are canonically lowercased. nama is an emad prefixed with a name like “Thomas Krichel ”. surk is a subscription in a profile meski is the message kind. The normal one is "repis" for a report issue. hopa is the homepage of a subscriber repcode is the identifier of a report. reporter the person (with name and email) that creates report issues. repis a report issue orima is the nama of the named reporter. * stylesheets docids.xslt.xml gets the document handle from indocs, one handle per line. maker_emad.xslt.xml gets the head_repis.xslt.xml has the headers for a repis, as XML text_repis.xslt.xml has the text for a repis, as text html_repis.xslt.xml has the text for a repis, as text orima.xslt.xml gives the orima * init file settings [folders][repis] sets the repis folder [folders][style] implementation dependent style sheets [folders][xslt] implementation-independent style sheets [folders][profiles] is the current subscription folder. [folder][destins] is the folder for the destins. * The omnibus the omnibus lives in the file omnibus.xml (no compression) in the profiles directory. It contains surks that get all reports. The structure of the document is in etc/omnibus.rng.xml. The document can not have two surks with common emads but different data. The latter data—in document order—overrides the former. * Stylesheet Stylesheets are used to set the head, the html and the text of an email. At this stage, we only have one way to style a repis, given in conf['sheet']['repis_head'] conf['sheets][repis_text] and conf[sheets']]['repis_html']. conf['sheets]['repis_head'] head needs to be there. We need one of the two others.