= Сообщение: 2487 из 3030 =================================== GANJANET.LOCAL = От : Mithgol the Webmaster 2:5063/88 14 Oct 07 00:30:12 Кому : All 14 Oct 07 00:30:12 Тема : [5/11] FidoURL.txt FGHI : area://GANJANET.LOCAL?msgid=2:5063/88+47112b59 На : area://GANJANET.LOCAL?msgid=2:5063/88+47112aee = Кодировка сообщения определена как: CP866 ================================== ============================================================================== * изначально написано в эхоконференцию FTSC_Public * также было отослано в эхоконференцию GanjaNet.Local * также было отослано в эхоконференцию Ru.Fido.WWW * также было отослано в эхоконференцию Ru.FTN.Develop * также было отослано в эхоконференцию SU.FidoTech * также было отослано в эхоконференцию Titanic.Best
textsection 5 of 11 of file FidoURL.txt textbegin.section
7.1.2. Dealing with unknown containers -+------------------------------------
Sometimes an <object-path> designates an object inside such a container that certain Fidonet browsers are not able to open by themselves. This MAY happen when the archive format is unknown (or is known, but is newer than the supported one).
If the object is requested as a separate entity (for example, its URL is entered in the address line of a Fidonet browser, or the user follows a hyperlink specifying that URL), the browser MAY inform the user about the unknown container encountered, and suggest saving that container for possible manual analysis (after all, the user may have unpacker tools in his avail that are not yet integrated into a Fidonet browser, and may be willing to try them).
If the requested object is not a separate entity (for example, if it is just one of images on a hypertext page), if many such objects are requested at the same time and for the same purpose, then it would not be wise to flood the user with information about each of such obstacles concurrently encountered, and so the browser SHOULD follow its standard procedures prescribed for the state of error (display a "broken image" icon, or use an alternate object or an alternate text where it is provided).
7.2. "area://" scheme -+-------------------
Echomail is an important and powerful force in Fidonet. Echomail is, by definition, a broadcast medium. See echomail specifications in FTS-0004.
An echomail area is a shared base of messages that have common areatag (area identifier) and are distributed through Fidonet via hierarchical and/or p2p-alike connections between individual Fidonet systems (nodes and points).
Due to the immanent modularity of Fidonet software packages, echomail composer and echomail browser can be different programs (for example, the latter does not require read/write access to the area message base and is able to work through a read-only gate). The "echomail:" scheme (defined above) is designed to designate an action of a Fidonet echomail composer; the "area://" scheme, defined is this section, designates a resource that is located in an area message base. These schemes can be handled by different software modules, even if they were manufactured independently.
The area URLs take the form:
area://<areatag>/<object-path>?<optional-part>
The character "/" has its literal meaning in the <optional-part> of URLs of this scheme. The character "/" has its reserved meaning in the required part of URL (<areatag>/<object-path>), playing the role of delimiter between parts of the path. If an <areatag> contains the character "/" in its literal meaning, the character MUST be encoded.
If <areatag> is empty, the <object-path> MUST also be empty; such URL leads to the list of the available echomail areas, also known as the arealist.
Examples:
area:// area:/// area://?
If <object-path> is empty and <areatag> is not empty, the URL defines a set of echomail messages. Depending on the URL, that set MAY contain a single message, or several messages, or no messages at all. The <areatag> part of URL defines the initial message set which is then filtered (see section 7.2.1 below), and the filtered message sets are combined to form the final message set, which finally is the desired resource, which is designated by the given URL.
If the <areatag> contains just one areatag, then the initial message set MUST consist of all the messages of the echomail area that corresponds to the given areatag.
However, <areatag> of "area://" URL MAY contain several areatags (separated by spaces). In this case the initial message set MUST consist of all the messages from all of the echomail areas labeled by given areatags.
Any of the areatags MAY contain "@domain" suffix (see subsection 5.2.2.3.1).
If an areatag corresponds to an echomail area which is not available on the system, then the initial message set is not complete, and the Fidonet browser SHOULD display some warning about it. For example, the warning MAY contain an URL like areafix:areatag>https://fido.g0x.ru/?areafix:areatag>areafix:areatag and the user MAY be asked whether he wants to subscribe and rescan the missing echomail area from the uplink. A warning is especially RECOMMENDED when all of the given areatags correspond to the missing echoes.
Any of areafix:areatag>https://fido.g0x.ru/?areafix:areatag>areafix:areatag URLs in such a warning, if present, MUST preserve "@domain" suffixes given in the "area://" URL for missing areas.
(If <object-path> is empty and <optional-part> does not contain message filters, then the area URL designates an area as a whole.
In this case, if the area is not available on the system, the browser MAY redirect its user to some external echomail storage, such as WebBBS or Usenet mirror.)
The final message set, determined by the URL, MUST also be formed if <object-path> is not empty. However, in this case it is not the final message set itself that is designated; in this case the URL with existing <object-path> corresponds to some object contained in the final message set. (See subsection 7.2.2.2 to find out how the designated object is determined.)
7.2.1. Message filters -+--------------------
It is possible to design an URL to designate not the whole echomail area(s), but a narrower subset of its (their) messages. Special optional parameters, so called message filters, are used for this purpose in URLs. They contain the particular properties of desired messages: it can be the message origin, or date and time interval, or some text fragment (more or less unique), or a kludge.
If at least one of the message filters is present in the <optional-part> of an area URL, then
area://<areatag>?<optional-part>
no longer designates the whole message base of the given area, but only a subset of its messages; the subset is defined by the given value of the message filter(s).
If <optional-part> contains only one filter, the final set of messages (designated by the URL) is equal to the filtered set specified by the only filter.
If <optional-part> contains several filters, the final set is a combination of individual filtered sets specified by individual filters. They are combined to form either unions or intersections.
In set theory and other branches of mathematics, the union of sets is the set that contains everything that belongs to any of the sets, but nothing else. If A and B are sets, then the union of A and B is the set that contains all elements of A and all elements of B, but no other elements.
The intersection of two sets A and B is the set that contains all elements of A that also belong to B (or equivalently, all elements of B that also belong to A), but no other elements.
Since filters are optional parameters, they appear in "parameter=value" form. Parameter's name is filter's type:
<type of the filter>=<value>
Several filters of the same type MAY appear in the same URL.
It takes the following two steps to form the final message set, determined by the URL:
1) Filtered sets defined by message filters of the same type are combined. Depending on the type (see details below), they form either unions or intersections, and that formed sets are called type-total sets below. Thus, for each of message filter types described below (in subsection 7.2.1.1, in subsection 7.2.1.2, and so on), its own type-total set is formed.
2) Type-total sets of different filter types (formed by the previous step) are combined and they form the final message set. This MUST always be the intersection of type-total sets, so the final message set contains only the messages that belong to each of the type-total sets.
CAUTION! Filter types that are absent in the given URL MUST NOT be considered: if none of the specified filters in the given URL belong to some certain filter type, then the corresponding type-total set (for that filter type) is empty, but that empty set MUST be ignored while forming the final intersection. (Otherwise the final message set would be empty unless each of the possible message filter types are present; that's not intended.) However, a type-total set MAY be empty for a present filter type; in such case the empty set MUST NOT be ignored. That's why some caution is needed to distinguish between empty sets of absent types and empty sets evaluated as type-total sets of present filter types.
(For example, if the URL contains no filters of "msgid" type, then the type-total set for "msgid" type is empty, but ignored; however, if the URL contains one "msgid" filter that contains a message ID that corresponds to a missing message, then the empty type-total set for "msgid" type leads to an empty final message set.)
PERFORMANCE HINT: the speed of evaluation MAY be improved by the mere fact that the final message set is always an intersection of type-total sets. A message MUST appear in each of type-total sets in order to become a part of the final set. That's why, if one of the type-total sets is already evaluated, all the other message filters MAY be applied to that type-total set instead of the initial message set: it is safe to skip the messages that are present in the initial message set but are absent in that type-total set, because they won't appear in the final message set anyway.
Example: if the given URL contain several filters of "msgid" type and several filters of "find" type, then it is wise to start with evaluating the type-total set for "msgid" type (which is likely to contain just a few messages); then it becomes safe to apply the "find" searches only to the messages of that narrower set, and it spares us the trouble of looking through the entire initial set.
7.2.1.1. Filters of "msgid" type -+------------------------------
The "msgid" filter is used to designate a single message in the given echomail area(s). The value of such a parameter contains the contents of MSGID kludge of that message, but without the leading "^MSGID: " string.
MSGID kludges are defined in FTS-0009 and serve well as unique message identifiers for echomail messages.
A message from the initial message set appears in the filtered set (defined by a "msgid" filter) if and only if the message contains the MSGID kludge equal to the value of the filter.
Most likely, the filtered set contains only one message. It MAY contain several messages, because though FTS-0009 states that two messages from a given system MAY NOT have the same serial number within a three years, the message base itself MAY span more than three years. In this case, the URL's author SHOULD apply other filters (a filter of "time" type, for example) to ensure the desired period of time.
(The meaning of "time" filters is described below.)
Note that the "msgid" filter MAY designate such a message that is not present in the initial message set. In this case the filtered set is empty. A Fidonet browser MAY collect such events as minor warnings and MAY implement some user interface for the user to ask uplink(s) for a rescan of the area(s), or to query some external archive of Fidonet echomail messages in search for the desired messages, or to try some other means of getting the desired messages.
If there are several "msgid" filters in <optional-part>, then the type-total set for "msgid" type is formed as the union of their filtered sets.
7.2.1.2. Filters of "time" type -+-----------------------------
The "time" filter uses the DateTime field of Fidonet messages (as defined in FTS-0001) to filter them checking the date and/or the time each message was written at. The filtered set contains only those messages that match the given moment of time, or belong to the given interval of time. The contents of a "time" filter are more complex than the DateTime format; the possible forms of a "time" filter are enumerated below.
If the message base does not use DateTime field as defined in FTS-0001, the analogous part of the message header MUST be used to get the necessary date and time. For example, JAM bases use the DateWritten field in a MessageFixedHeader structure, and Squish bases use the date field in a SCOMBO type, etc. The term "DateTime" is used below for such cases as well, it's a generalization.
7.2.1.2.1. Single moment -+----------------------
The most basic form of a "time" filter's value contains just one moment in time, in the following form:
The <Year> value MUST always be four or more digits (zero-padded if necessary). It MAY have "BC" suffix (for example, "0023BC") to designate years before the Common Era, though right now there's no software technically able to date Fidonet messages as such.
The <Month> value MUST always be two digits: 01 for January, 02 for February, ..., 11 for November, 12 for December.
The <Day> value MUST always be two digits: 01 for the first day of the month, 02 for the second, etc.
The <Hour> value MUST always be two digits, from "00" to "23".
The <Minute> value MUST always be two digits, from "00" to "59".
The <Second> value MUST always be two digits, from "00" to "60". (The value of "60" is reserved for leap seconds, though they are rarely timestamped in Fidonet.)
A message from the initial message set appears in the filtered set (defined by the given single moment) if and only if the message's time is equal to the value of the filter. All the six values (year, month, day, hour, minute and second) are checked, unless some of them are empty in the filter.
textend.section
With best Fidonet 2.0 regards, Mithgol the Webmaster. [Real nodelisted name: Sergey Sokoloff]
... 66. My security keypad will actually be a fingerprint scanner. --- Orcs are near! My Golded 1.1.5-b20060515 is gleaming!.. * Origin: Be careful, the paranoid ones are always wathing you!.. (2:5063/88)
