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.)
• 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.)
• 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. The above list is in no way complete.