<h​into:monero.social> m​oneromooo: in JSON-RPC responses that have binary fields like `get_txpool_backlog`, do you know what type of binary it is? Epee? Bitcasted struct? asking because you wrote the line that does it: github.com/monero-project/monero/bl…re_rpc_server_commands_defs.h#L1660

<h​into:monero.social> in that case, it's `std::vector<tx_backlog_entry>`, how does the container get serialized? is it length + bytes?

KV_SERIALIZE is epee. _AS_BLOB is verbatim bitstream, plus probably type and length (likely varint).

Now, that is probanly broken, since one of the fields in that struct is a std::string, so as blob ought to write the internals of the string, which allocates for long strings...

Oh nvm, there are two structs with the same name in two different scopes. Seems OK.

<h​into:monero.social> what about _CONTAINER_POD_AS_BLOB? is it `[type, total_length, <bitstream>]`?

<h​into:monero.social> unless that is what you meant by _AS_BLOB, although there's a separate macro for values and not containers

<j​effro256:monero.social> That just serializes a string in the epee format. The length of the container is implied from the length of the string: container_len = string_len / bytes_per_element

<f​arooqkz:mozilla.org> Do people who translate monero stuff get money from community?

no. take that question to -community or #monero, though.

<f​arooqkz:mozilla.org> okay. sorry for being disturbing

<h​into:monero.social> jeffro256: thanks, so the `backlog` field in `get_txpool_backlog` is just epee?

<j​effro256:monero.social> Sorry that was if you're serializing in epee. In both epee format and JSON, _CONTAINER_POD_AS_BLOB simply serializes a string

<j​effro256:monero.social> it makes the same string (packed binary blobs) which gets serialized depending on which format you use

<r​ottenwheel:kernal.eu> jeffro256 PM when you can, thanks!

<v​tnerd:monero.social> No changes are done for format afaik. The caller is required to do convert bin to hex before giving it to the serialization system. This was something that I changed in my serialization patch - types that were blobs called a `binary(...)` function that did on the fly hex conversion when needed

<j​effro256:monero.social> Wouldn't that make new payloads not compatible?

<v​tnerd:monero.social> Im not sure what you mean. New payloads don't need to do the manual conversion anymore, just mark as binary.