You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the restricted profiles section of the spec is quite vague, and covers a lot of potential use cases. It's mentioned under "future discussions", well let's get that discussion started!
I believe that the only real way to implement such a broad goal would be to allow msgpack libraries to defer encoding/decoding of built-in msgpack objects to a user-supplied function, similar to how external types are handled now.
In my particular use-case I need msgpack to only encode immutable python types. That means I need to handle "map" types myself.
It might be simplest to have end users able to customize the mapping between language-types and msgpack types, overriding the libraries assumptions about type-coercion.
The text was updated successfully, but these errors were encountered:
Right now the restricted profiles section of the spec is quite vague, and covers a lot of potential use cases. It's mentioned under "future discussions", well let's get that discussion started!
I believe that the only real way to implement such a broad goal would be to allow msgpack libraries to defer encoding/decoding of built-in msgpack objects to a user-supplied function, similar to how external types are handled now.
In my particular use-case I need msgpack to only encode immutable python types. That means I need to handle "map" types myself.
It might be simplest to have end users able to customize the mapping between language-types and msgpack types, overriding the libraries assumptions about type-coercion.
The text was updated successfully, but these errors were encountered: