Post

Not sure how much my vote counts, but I'd say: Why not both? CBOR if I had to choose, but both have active ecosystems, and both would be good ecosystems to be able to work with. PowerShell should always be able to talk to as many standards as is possible and simple.

Choosing a single encoding format would simplify implementation complexity - but I made it work with Protobuf, CBOR and CLIXML for my PSRemoting gRPC transport: github.com/awakecoding/...

Cool! I have one simple additional ask, strange as it might seem: Allow a custom transform (preferably thru a [ScriptBlock] or [func[PSObject]] ) The goal here would not be universal operability, but specific high-performance compatibility. Otherwise it's always 'select *'

CBOR for me, and gRPC needn't change that, since it defaults to Protobuf but carries other formats too. Would PSRemoting over gRPC pass objects as an opaque blob, or map them into proper messages?

JSON or BSON are excluded, as they can't preserve 100% of PowerShell object properties the same way CLIXML would. I've tested the CBOR and Protobuf encodings to make sure all edge cases survive an encoding round trip

Cbor is the new, painful hotness

Notice how I haven't tried ASN.1 😅 but seriously though, CBOR is schema-less and great, Protobuf requires a schema, but could still be adapted to map CLIXML well. Protobuf is what gRPC uses, so the next step would be gRPC-based PSRemoting