Node:Future changes, Next:Protocol Version History, Previous:Some Client-specific Aux-Item Types, Up:Top

Future changes (speculative)

While useful and stable, this protocol is far from perfect. Here is a short list of things the current developers would like to change in future versions of the protocol. The list is not sorted.

All changes will be made in a backwards compatible way. Clients 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. (This is bug 133.)
• The information contained in the Misc-Info array should be integrated into the Text-Stat. There should be one array of recipients, one of texts that comments this text, and so on. This would make the Misc-Info type obsolete. (This is bug 134.)
• The aux-items can be very large. It was a mistake to include them in the Text-Stat. They should probably be separated from the Text-Stat; retrieving the Text-Stat should only indicate which aux-items that exists. (This is 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. (This is bug 93.)

• 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 original bit and introduce a followups-to field in the Conference. Doing this in a backwards-compatible way requires some thought... (This is bug 136.)

• The security system is too complex, yet unable to do many useful things, and should be rethought. (This is bug 137.)
• The last-text-read and read-texts fields of a 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. (This is bug 52.)
• The mark-as-read call is a reasonably good way to mark a single text as read (but one could argue that it should take a single Text-No and an ARRAY Conf-No as arguments), but there is no easy way to undo such an operation. You can use set-last-read followed by a number of mark-as-read calls to get the desired effect, but it would be nice to have a mark-as-unread call. (This is bug 53.)
• If the client issues several request without waiting for a reply, the replies will nevertheless always arrive in the same order as the requests were sent in. If a threaded version of the LysKOM server is ever made, it could possibly process two requests from the same client at the same time, and the answers could be returned in any order. However, the current clients are probably not written so that they can 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 ref-no to match each reply to the corresponding call. (This is bug 138.)

For more information about potential future changes, see Bugzilla @ Lysator.