Post

I've been experimenting with PSObject binary encodings to replace CLIXML - CBOR and Protobuf are both great candidates, with significantly smaller size, but also much faster encoding and decoding performance! Which one would you like to be supported natively in PowerShell?

James Brundage | MVP

@mrpowershell.com

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.

20/10/26, 9:29 pm0 reposts1 like

Marc-André Moreau

@awakecoding.com

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/...

github.comAdd Protobuf/CBOR/CLIXML PSRP encodings and in-process gRPC server by awakecoding · Pull Request #20 · awakecoding/AwakeCoding.PSRemotingSummary Replaces intermediate CLIXML and <Data>base64(CLIXML)</Data> framing in the gRPC PSRemoting transport with structured [MS-PSRP] gRPC packets (src/Protos/psrp.proto). Adds selec...

James Brundage | MVP

@mrpowershell.com

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 *'

Marc-André Moreau

@awakecoding.com

You mean combine Select-Object with the object exporting/importing? I'm building cmdlets for PSObject serialization/deserialization to go along my PSRemoting module right now

James Brundage | MVP

@mrpowershell.com

Not select-object (for various reasons, mostly performance) There are several major utilities: 1. Optionally thinning the message sent 2. Securing the message on the way out 3. Debugging the message before it goes out 4. Optionally using other protocols (udp, http, etc)