Support CBOR in foxglove studio visualizer

[therishidesai]

I want to use CBOR as the serialization/deserialization method but when I use the "cbor" message encoding type in my MCAP file the foxglove studio visualizer errors with the following:

Error: Unsupported encoding cbor
    at parseChannel (https://studio.foxglove.dev/1023.b8837902683ffb518450.js:1:7731)
    at McapIndexedIterableSource.initialize (https://studio.foxglove.dev/4766.761276315d65092c2625.js:1:1915)
    at McapIterableSource.initialize (https://studio.foxglove.dev/4766.761276315d65092c2625.js:1:11413)
    at async WorkerIterableSourceWorker.initialize (https://studio.foxglove.dev/4126.a9f9b288f40cab96776f.js:1:20965)

[jtbandes]

Also filed foxglove/mcap#763

[jtbandes]

See also: json-schema-org/json-schema-spec#6

[jon-chuang]

I don't think this is supported in foxglove yet? Shall I add a parseChannel branch for it? https://github.com/foxglove/studio/blob/0f3048689bbf66c7bbc9e7f7e1e9ebdb722fc186/packages/mcap-support/src/parseChannel.ts

Oh, wait, it seems we do not support schemaless message encodings in foxglove? https://github.com/foxglove/studio/blob/0f3048689bbf66c7bbc9e7f7e1e9ebdb722fc186/packages/mcap-support/src/parseChannel.ts#L51

The weird part is that we implicitly support schemaless - the only difference is that validation does not occur for the schemaless case, but we are still able to create javascript POJOs (i.e. Record<string, any>) https://github.com/foxglove/studio/blob/0f3048689bbf66c7bbc9e7f7e1e9ebdb722fc186/packages/mcap-support/src/parseChannel.ts#L64

Oh, I see, it seems that this issue has already been raised: #443

Shall we just support schemaless for both CBOR and JSON? I don't see any harm. Schema.name can also be "" indicating SelfDescribing.

Further, I think that we should also add self-describing as a valid schema type to the appendix: https://github.com/foxglove/mcap/blob/929e90d75fa1b7ccfc01721cde69a2826d484e1f/python/mcap/mcap/well_known.py#L20

[jon-chuang]

Further, I think that we should also add self-describing as a valid schema type to the appendix: https://github.com/foxglove/mcap/blob/929e90d75fa1b7ccfc01721cde69a2826d484e1f/python/mcap/mcap/well_known.py#L20

Need confirmation if we should remove "" as a valid schema label. I think it's unnecessary and we should drop it.

[defunctzombie]

Indeed you can drop "" as a schema name as that is handled by the spec by using a schema_id of 0 in the channel.

[jtbandes]

We've already documented the "" schema encoding here: https://mcap.dev/specification/appendix.html#empty-string

[amacneil]

What's the advantage of using schema encoding "" versus schema_id=0?

I guess it is plausible someone might want to give their self describing schema a name even if there is no actual schema available?

[jon-chuang]

I guess it is plausible someone might want to give their self describing schema a name even if there is no actual schema available?

Hmm, that actually does seem reasonable, even if semantically redundant

schema_1:
  name: unstructured_json
  data: 
 
channel_1:
  name: raw_data
  schema_id: 1

I suppose whether this is reasonable depends on whether the self-describing schema's name turns up anywhere in debugging or inspection (e.g. in the panel info).