Hello On Tue, Jul 19, 2022 at 10:01 PM Kiran Shila <[email protected]> wrote: > > but there are use cases where multiple GBytes of data are moved through > > katcp > This is a crazy to me as clearly the protocol is not meant for this > purpose.
So quite a number of people have worked on the katcp protocol specification over the last decade or so, and everybody has of course had a slightly different view on it, so what it "meant" to do is fuzzy. But I always intended it to be plain text where possible but able to handle arbitrary data where necessary. > > 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? The BNF defines an argument as one or more characters, of which 7 have to be escaped. It does not define what a character is, and now looking back that is a deficiency, but to my mind a "control character" or "non printable character" are a subset of "character". Maybe "octet" would have been better... Then there is also "Where message parameters are described as `human-readable' the content of the parameters should be restricted to plain ASCII text" (pg11) but that is for parameters which are documented to be human readable - and I'd be surprised if all the parameters "?write" and "!read" are described as such. regards marc > > > 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. -- https://katfs.kat.ac.za/~marc/ -- 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/CAGrhWaS9Si3LESq76eoEezmrU6geXYjkHV3CdzPeMr5j_Xzd4w%40mail.gmail.com.
