On Thu, Jan 17, 2019 at 3:32 PM Neil Van Dyke <n...@neilvandyke.org> wrote: > > Just one off-the-cuff alternative representation, with some properties > that might be useful to you... > [...much good stuff about string encoding...]
Thanks, those are all good thoughts. We get to control how much data is sent so yes, I could encode it to base64 with relevant prefixes. That said, it's going to go into a protobuf, which will then crunch it into bits, so it's probably easier to use the crypto library to turn it into bytes right from the start so that protobuf doesn't do another pass. Related topic: I mentioned the crypto nature mostly as context; I'm interested in the answer to the question for general purposes, since it would be nice to be able to do some slicing and dicing in the parsing pattern as opposed to doing it manually afterwards. Is there a way to do it? > (In any case, I'd try to avoid XML for the above purpose, unless > mandated. XML is overpowered for that purpose. I've seen systems use > XML for the above purpose alone, which is extra system complexity, extra > time and space costs, and perhaps more programming work. I've also seen > design problems in this sort of thing, which I suspect were obscured > from the programmer by the representational bulk and programming work of > XML. Oh, hell yes. There are very few things for which I would voluntarily choose XML, and sending data over the wire has never yet been one of them. Thanks for the nudge. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
