Fred, any chance you can change the current SendNetworkString() to behave similar to my SendNetworkStringUTF8() and add a ReceiveNetworkString() similar my ReceiveNetworkStringUTF8() ?
The current one does not handle unicode, only ascii right? And considering that ascii is able to carry UTF8 a new SendNetworkString() will still remain backwards compatible with old/current ascii programs. As for old unicode programs...those are broken anyway with the old SendNetworkString()
The string function was just a convenience function. You don't send 'strings' over the network, just bytes. You can send unicode string same way as normal strings, as sequences of bytes. ReceiveNetworkString would make no sense and there'd be no good way of knowing if the bytes being received were supposed to be a string, let alone what type of string.
Did you see my example in the other thread?
All strings are treated as UTF8, 99% of all ascii will be accepted as-is by UTF8 so hardly an issue.
Also, there is a send/receive File currently.
I think that send/receive file, + send/receive data, + send/receive text, would be a nice trio of network functions, especially if strings are given a event flag. That way a game client/server can react to the event type. obviously a server in particular but a client as well should always check if the received data, whether it is data, a file or a string that is valid. But it does allow a virtual 3 channel data transfer. (raw data, file data, string data)
send/receivefile already uses a safe marker to indicate it's a file and not raw data, shouldn't be much harder to do the same with strings if the strings are made to be UTF8 which is platform and byteorder independent.
Well, I suppose since I was against SendNetworkFile as well...
If this is to be the path of the pb netlib I think a settable option should be allowed in initnetwork() to disable any receive events except data, to allow for more 'pure' use
