Guids serialized as strings even though the compatibility option is set to None

[moozzyk]

If you use the following code to serialize a GUID value:

using (var ms = new MemoryStream())
{
    var packer = Packer.Create(ms, PackerCompatibilityOptions.None);
    packer.PackObject(Guid.NewGuid());
}

I will get the following result:

0xb0, 0x49, 0x92, 0xa0, 0x7d, 0xb2, 0x98, 0xfe, 0x4a, 0x97, 0xfe, 0xaf, 0xd9, 0xae, 0x91, 0x0e, 0x49, 0xb0, 0x2d, 0xd9, 0x75, 0xb6, 0x94, 0xa0, 0x5d, 0x4c, 0xb4, 0x4c, 0xe0, 0xd5, 0xad, 0x55, 0xeb, 0x67

so, the binary array representing the GUID has been serialized as a string of 15 characters (0xb0). My expectation was that because I used PackerCompatibilityOptions.None the byte array for GUID will be serialized as bin8 family (0xc4).

Looking at the code it seems that binX family is never considered when packing raw values. I would like to understand why this is the case and how raw values are typically unpacked if the language does not have strong type system (e.g. in JavaScript this GUID will be unpacked as string - is it then the user's responsibility to extract bytes?)

[yfakariya]

Thank you for feedback. There are two considerations about it.

1. It is a bug that built-in Guid serializer does not honor PackerCompabilityOptions (

   msgpack-cli/src/MsgPack/Serialization/DefaultSerializers/DefaultSerializers.cs

   Line 323 in 4586454

   packer.PackRaw( value.ToByteArray() );

   )
2. Raw bytes should be unpacked as 'bytes which MAY be UTF-8 encoded string' because there were no binX famaliy in past. I think it is application's responsibility to specify the raw value is truly string or not.

[moozzyk]

1. So to recap, the built-in Guid serializer could/should use the binX family if the user passes PackerCompatibilityOptions.None.
2. I came to the same conclusion. If the language does not have a strong type system or the client does not have a type that corresponds to the server type, the user/developer is the only one who knows how to interpret the data. If this is hard they might need to work around it, possibly, by using a different type.

[yfakariya]

I recognized that there are same bug for some other types. I will fixed it for next release (maybe RC)