I found the original proposal too ugly.

alternative to msgpack-update-proposal2.md

Overview

See https://gist.github.com/frsyuki/5028082 Before reading further.

Changes on the type system

Instead of filling empty slots with a bunch of Extended types, I propose adding just one type.

• Typed: a tuple of type and byte array.

  0xc1: Marker, followed by two MessagePack objects

+--------+--------+--------+
|  0xc1  |TTTTTTTT|XXXXXXXX|
+--------+--------+--------+
Where:
  TTTTTTTT is an MessagePack object that represents the type of XXXXXXXX
  XXXXXXXX is the value thereof

Tuple as FixArray-2 or FixMap-1

Consider the following json:

[0, "Crüe"]

Note "Crüe" is in UTF-8

Current MessagePack turns it into:

0x92:FixArray with two elements
0x00:FixInt 0
0xa5:FixRaw with 5 bytes
0x43:'C'
0x72:'r'
0xc3:'ü' - uppper half
0xbc:    - lower half
0x65 'e' 

Which is only two bytes longer than "Crüe".

Instead of a two-element array, you can use one-element map as:

{0:"Crüe"}

In which case the first 0x92 becomes 0x81.

My proposal simply:

• replace 0x92 or 0x81 to 0xc1 to mark this is a special type of FixArray 2
• store type info (FixInt should suffice for most cases) in the first element
• and its value in the second element.

As a matter of fact…

Proposals to use 0xC1 as a marker repeatedly appear msgpack/msgpack#121 . Though rejected as @kazuho commented, IMHO this remains the most unintrusive way to add type.

Thank you for your proposal. The option was considered in msgpack/msgpack#121 (comment), but was not chosen due to the following reasons:

• strings are one of the most frequently found data, and adding 2-byte overhead were considered too much
• if such change were made, existing decoders would become unable to parse strings sent from encoders conforming to the new spec.

• You still lose a byte in the new proposal.
• Whichever proposal realized, you can't decode new MessagePack stream with exisiting encoders anyway.