Commit d8072492 authored by Per Cederqvist's avatar Per Cederqvist
Browse files

(Future changes): Entered all future changes into Bugzilla. Refer to

	Bugzilla.  (Bug 131).
parent e9a894ff
......@@ -9167,26 +9167,30 @@ will still be able to use the old requests.
Cryptography! LysKOM is sometimes used for sensitive information. It
is unacceptable that everything is sent in the clear. Should we use
TLS? This area needs further study.
TLS? This area needs further study. (This is
@uref{, bug 133}.)
The information contained in the @type{Misc-Info} array should be
integrated into the @type{Text-Stat}. There should be one array of
recipients, one of texts that comments this text, and so on. This
would make the @type{Misc-Info} type obsolete.
would make the @type{Misc-Info} type obsolete. (This is
@uref{, bug 134}.)
The aux-items can be very large. It was a mistake to include them in
the @type{Text-Stat}. They should probably be separated from the
@type{Text-Stat}; retrieving the @type{Text-Stat} should only indicate
which aux-items that exists.
which aux-items that exists. (This is
@uref{, bug 135}.)
There is too few asynchronous messages. There are many situations
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.
is the best. (This is
@uref{, bug 93}.)
The super conference is used for two purposes: to indicate where
......@@ -9198,10 +9202,13 @@ 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{}
(This is
@uref{, bug 136}.)
The security system is too complex, yet unable to do many useful
things, and should be rethought.
things, and should be rethought. (This is
@uref{, bug 137}.)
The @field{last-text-read} and @field{read-texts} fields of a
......@@ -9210,7 +9217,8 @@ 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.
read texts. (This is
@uref{, bug 52}.)
The @reqlink{mark-as-read} call is a reasonably good way to mark a
......@@ -9234,10 +9242,14 @@ handle such reordering.
In the future, a new call might be added, so that a client can give
the server explicit permission to reorder the replies. The client
would then have to rely on the @field{ref-no} to match each reply to
the corresponding call.
the corresponding call. (This is
@uref{, bug 138}.)
@end itemize
For more information about potential future changes, see
@uref{, Bugzilla @ Lysator}.
@node Protocol Version History
@appendix Protocol Version History (informative)
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