Peter wrote:
I find it exaggerated to say that TCP/IP is useless without encryption. It can still be used for LAN connections, internet connections from QL to QL, and many websites.
From my experience with QLwIP I see the largest problem in the requirement of encryption for email server connections. (Which does not even make too much real sense, as long as the contents is usually cleartext.)
I don't think TCP/IP is useless without encryption, but a TCP/IP device made now will already not have access to half the services available, and this will only increase in the future.
Peter wrote:It would take similarly long to render a webpage (in the hypothetical assumption the QL had a graphical browser). But what kind of encrypted internet data would you process on a QL? (Except text email which would still make sense on slow machines.)
I was thinking encrypted email, SSH, SFTP, secure chat, etc.
Peter wrote:I see a difficulty in "outsourcing" TCP/IP: It leads to the emulation route, moves development away from the native side. Eventually it is no longer clear why we do not emulate the rest of the QL side also, if the network coprocessor has much more processing power anyway...
Almost all the existing communications software on the QL is designed to use a Hayes compatible modem. This method we implemented is Hayes AT compatible to the point where devices can function across a TCP bridge, transparently.
I consider that far more immediately useful that some device that doesn't run the stack for the vintage OS with some hardware abstraction layer to present a common and familiar interface. This both protects us by allowing us to use the same mechanism for future versions of the wifi chipset, AND it makes the use of it immediately accessible to everyone who knows how to use a modem -- no extra knowledge required.
That's not a worse or less viable choice than using a chip that currently has no released OS support, isn't used by any released software (vintage or otherwise) and even when it does, will have to use plaintext or some archaic form of encryption that is not compatible with modern and future systems.
Both are choices. Both are valid. Both get people online with their QLs. One is easier and more abstracted, and gives less control but fewer difficulties. The other is more fundamental, and requires deep and intimate knowledge of the OS and additional tools to operate. So one suits me and my skills, and one suits you and your skills.
That's why they do not each appeal to us equally.