Commit 8d52582c authored by Per Cederqvist's avatar Per Cederqvist

(Articles): Clarify the discussion about local and global text numbers.

(Persons and Sessions): Make this a @section instead of a
	@subsection to Conferences.
(The Misc-Info List): Mention that bcc-recpt are converted to
	cc-recpt only when visible.
(Client-Server Dialog): Spelling error fixed.  Mention that
	not-implemented works only if the client follows the strict
	rules regarding whitespace in protocol requests.
(set-conf-type): Name the "four-bit conference type".
(get-conf-stat-old): This returns a Conference-Old, not a Conference.
(Future changes): Complain about super conferences, the securty
	system, and last-text-read/read-texts.
parent 13768ea9
......@@ -8,9 +8,12 @@
@c FIXME: error-reply defined twice (conflicting).
@c FIXME: add link to Name Expansion from relevant reqs.
@c FIXME: Name Expansion collate table info is outdated.
@c FIXME: Overview -> Preface
@c FIXME: Move syntax from overview to somewhere else
@c FIXME: sentence-end-double-space!
@c FIXME: "Foo bar (bar baz.)" or "Foo bar (bar baz)."?
@c
@c $Id: Protocol-A.texi,v 1.132 2001/05/01 17:11:24 ceder Exp $
@c $Id: Protocol-A.texi,v 1.133 2001/05/01 18:14:50 ceder Exp $
@c %**start of header
@setfilename protocol-a.info
@settitle LysKOM Protocol A
......@@ -447,6 +450,7 @@ conferences and sessions.
@menu
* Articles::
* Conferences::
* Persons and Sessions::
* The Misc-Info List::
* The Aux-Item List::
* Security::
......@@ -465,21 +469,24 @@ Each article is kept in the database until it is older than the
@field{nice} value of each of its recipients and it is not marked by any
user.
Currently there is an array of @type{Misc-Info} included in the
@type{Text-Stat}. This array contains information about recipients,
There is an array of @type{Misc-Info} included in the
@type{Text-Stat}. This array contains information about recipients,
senders, comments and footnotes.
Every article has at least one number, the global article number. Global
numbers are assigned in ascending order to new articles, and are never
reused. If an article has recipients it will also have a local number
for each recipient. Local numbers are used in some data structures to
provide more compact storage and to provide an ordering of articles for
a particular recipient. Local numbers are assigned in ascending order
and are never reused for a particular recipient, though different
recipients will have articles with the same local numbers.
Each article is identified by a number, the global@footnote{The number
is not truly global; it is local to a specific LysKOM server.}
article number (the @type{Text-No}). Global numbers are assigned in
ascending order to new articles, and are never reused. If an article
has recipients it will also have a local number for each recipient
(the @type{Local-Text-No}). Local numbers are used in some data
structures to provide more compact storage and to provide an ordering
of articles for a particular recipient. Local numbers are assigned in
ascending order and are never reused for a particular recipient,
though different recipients will have articles with the same local
numbers.
Occasionally it is necessary to map between local and global numbers.
The server call @reqlink{local-to-global} does this.
The server call @reqdlink{local-to-global} does this@linkhere{}.
......@@ -533,12 +540,8 @@ changed to this type, preexisting secret members remain secret.
@menu
* Persons and Sessions::
@end menu
@node Persons and Sessions
@subsection Persons and Sessions
@section Persons and Sessions
Persons are represented in the protocol by values of the type
@type{Person}. Associated with persons are statistics, a set of personal
......@@ -639,7 +642,9 @@ server.
This type of group was introduced in protocol version 10. When
old-style calls such as @reqlink{get-text-stat-old}
are used this will be converted to a CC recipient group by the server
for the benefit of clients that don't understand this group.
for the benefit of clients that don't understand this group. (This
conversion will of course only be performed when the user is allowed
to se the blank carbon copy.)
@table @misc
@item bcc-recpt
......@@ -1397,7 +1402,7 @@ The format of the string should be @var{username} % @var{hostname}.
When the server has accepted the connection its reply is
protocol-dependent. Protocol A servers will reply with the string
@code{LysKOM} on a single line if the connection attampt is successful.
@code{LysKOM} on a single line if the connection attempt is successful.
@example
% telnet kom.lysator.liu.se 4894
......@@ -1478,7 +1483,9 @@ separated by any number of linefeed (ASCII 10), return (ASCII 13), tab
(ASCII 9) or space (ASCII 32) characters. Servers should be forgiving
and understand requests using the older conventions, but clients must
conform to the current convention of separating data elements with
spaces and terminating all requests with a linefeed character.
spaces and terminating all requests with a linefeed character. The
@errorcode{not-implemented} error code will not be returned properly
unless the client follows this requirement.
If the request is syntactically incorrect, the server will respond with
the string "%% LysKOM protocol error." The server will attempt to
......@@ -4053,8 +4060,8 @@ Not enough permissions to change super-conference of conference
Sets the conference type of conference @rarg{conf-no} to @rarg{type}.
Before protocol version 8, @rarg{type} could only be four bits. Starting
with protocol version 8, either a four-bit conference type or an
@type{Extended-Conf-Type} is allowed.
with protocol version 8, either a four-bit @type{Conf-Type} or an
eight-bit @type{Extended-Conf-Type} is allowed.
@reqexample
@example
......@@ -5490,7 +5497,7 @@ This call retrieves the conference data structure for conference number
Important note: This call does not return the extra flag bits that were
introduced in protocol version 8. To get this information, use the
@req{get-uconf-stat} call instead. However, clients should be able to
handle @type{Conference} structures with an arbitrary number of flag
handle @type{Conference-Old} structures with an arbitrary number of flag
bits since we may decide to change the behavior of this call in the
future.
......@@ -9009,6 +9016,30 @@ where something can change without a client noticing it.
There is more than one way to fix this, and it is not known which way
is the best.
@item
The super conference is used for two purposes: to indicate where
followups of original conferences should be sent, and to indicate
where articles created by persons that are not permitted submitters
should be sent. Occasionally one wants to send followups to one
conference and unauthorized original articles to another conference.
One way to fix this is to remove the @conftype{original} bit and
introduce a @field{followups-to} field in the @type{Conference}.
Doing this in a backwards-compatible way requires some thought@dots{}
@item
The security system is too complex, yet unable to do many useful
things, and should be rethought.
@item
The @field{last-text-read} and @field{read-texts} fields of a
@type{Membership} is a very poor way to store information about what
is read. Consider the case where somebody has read everything up to
text 100, and text 102-2002. Using the current protocol specification
more than 2000 numbers must be transmitted to convey that information.
A much more attractive solution would be to send a list of ranges of
read texts.
@end itemize
@node Protocol Version History
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment