It seems like the easiest way to make everybody satisfied is to fix the above issue, which is a) objectively broken, not "just" non compliant; b) absolutely cannot possibly be that hard to fix. (Take the snap/pi version of tcpborphserver, find the "actual" fpga read/write call within the wordwrite/ wordread command, and replace it with an appropriate SPI call)
This is probably a good move, as it's not documented that this feature is even broken. To be more precise, reads from wordread return garbage, not just errors.
but there are use cases where multiple GBytes of data are moved through katcpThis is a crazy to me as clearly the protocol is not meant for this purpose. Especially when the "open a second socket connection to stream raw data" already exists as a solution.
Could the problem have been solved without breaking the ascii requirement - sure. Why was it not? I don't know.
Again - why even have a formal specification if official implementations break it?
Changing the tcpborphserver behaviour of read/write in a way that is not backwards compatible with casperfpga (and every other preexisting casper katcp client) seems unlikely to me to be a goer. Obviously you could do it to meet your needs/desires, but this code isn't going to ever get merged into the main repos/branches (you might reasonable ask whether this matters, given how many distinct, incompatible code branches are already lying around). In any case, making new bulk transfer commands which are compliant, and work with the client you're building seems like a path which should keep everyone happy(?)
For sure. I wasn't expecting anyone to actually update read and write, I was just providing an alternative should anyone want. Having a third option, (maybe `bulkread` and `bulkwrite`) that follows the spec sounds like it may be worth it.
If we're actually worried about throughput, there are a number of solutions that pack binary data into plaintext relatively efficiently. Base64 is common in the web space, as well as compressing and then packing. Again, it seems like it would be better just to open another socket and not deal with the hassle.
-Kiran -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/af99003f-574f-4593-3a08-995a3dbdbff0%40kiranshila.com.
OpenPGP_signature
Description: OpenPGP digital signature
