My initial goal with EXOS integration is for network LOAD/SAVE in BASIC to work (and other applications of course) and I was thinking first of LOAD "ftp:blahblah" etc. (or LOAD "http:blahblah" as we have discussed before). Here the protocol on top of TCP/IP is FTP and the EXOS FTP: device will handle that.
I see, but I guess then you an even open a channel and use that for reading, if it's usuable with LOAD too. FTP is bit more problematic too, as also a firewall administrator (among many other things) I can say, that FTP is a stone aged horrible protocol, it needs another tcp connection for data, and it can be passive / active FTP which also means the "direction" (who is the listener, I mean). Not counting ASCII/BINARY transfer etc (but I guess binary is OK if you can do that only). I try to avoid FTP if it's possible, eg via HTTP you can download anything too (or even upload, but that's some kind of other stuff, namely the DAV protocol over HTTP). But I can understand of course that many people would be happy with FTP as many sites provides FTP download, which can be used with EP directly then.
What you are talking about is the EXOS app implementing a different protocol itself on top of TCP/IP, eg POP3 in your example, and I have not given much thought to that, but it needs to be possible. eg open a channel to "NET:192.168.0.20:1001" (can you have two : s and a filename that long?). But at least in this case the application is network-specific so it can work
Btw, this is what I've already talked about: that's EXOS filenames are limited in size, which can be problematic, maybe not here, but even with FTP and/or HTTP. That's why I've suggested the "network resource declaration" with an EXOS command and you can only refer it when opening a channel. Of course, if name is suitable (eg: short enough, and does not contain character(s) forbidden by EXOS) the direct naming (what you've wrote as an example with FTP) is more than OK.
whatever EXOS's blocking-or-not behaviour is. EXOS has a read status call which says whether a character is ready or not (shame it doesn't say how many are ready!
) and I would say block read should return whatever is available, possibly less than the user asked for. Surely protocols are designed so the "reader" knows how many bytes he is supposed to read? In the case of POP3 the responses from the server are single text lines which you could read character-by-character, or as a block returning however many are available, and then when a mail message itself is downloaded you already know how many to expect, so you loop doing block reads until you have the message, presumably with a timeout. Avoiding a waiting-for-network loop within EXOS seems like a good idea if at all possible!
I think POP3 is line oriented protocol more or less as iRC is too. What a simple app can do, is try to read "some bytes" and check if it's line terminated. If not, try to read more bytes, by appending the buffer. If line termination is found, then the line can be processed, and the possible left bytes are used again to try the first line terminator, or waiting for more bytes, etc.
Otherwise POP3 is not so hard, there can be an app over plain TCP/IP stream for basic mail client (IMAP at the other hand is more complicated, but it also gives the possibility of mail folders, with POP3 there is not such a thing). Also sending mail is not so complicated, if TLS etc stuff is not needed, the SMTP authentication with the PLAIN scheme can be done (but it requires base64 encoding).
Just, if you think about a simple app: it should poll the network for incoming data, but it has other tasks, ie user keyboard handling, screen updating etc. So what I would do, is checking if there is any data (so EXOS can do this) then I try to read data with size of the maximal possible (for our buffer in EP RAM, I mean). That's my problem, that an EXOS read function requested for n bytes can return with less bytes. Or if it can (it can, if I remember exactly) is it a good strategy, would it work with LOAD etc, or it should wait a bit for more data? Because the "common behaviour" with disk files that EXOS will return "n" bytes if "n" bytes are asked (unless if EOF is got of course ...). So I am not sure if applications are ready for this behaviour, that it will be much more common that read return with less bytes than eg with disk files. Of course a network-aware app (eg POP3 client ...) will know this, but we would like that existing software can be adopted easily just with opening let's say NET:1.2.3.4:110 instead of a name for a file on the disk. And it even includes eg BASIC's LOAD if it can handle this situation well enough, or if it gets less bytes than it requested then it's interpreted as end-of-file, since basically - AFAIK - this can be only the case if end of file is hit meanwhile if you work with disk files.