Data track schema definition storage

[ladvoc]

Adds support for defining/retrieving data track schema definitions through new methods on local participant. Under the hood, this is powered by data blobs.

Mirrors the implementation in: livekit/rust-sdks#1159.

Usage (publisher):

const schemaId: DataTrackSchemaId = { name: 'sensor-reading', encoding: 'jsonSchema' };

await room.localParticipant.defineSchema(
  schemaId,
  JSON.stringify({
    type: 'object',
    properties: { temperature: { type: 'number' } },
  }),
);

Usage (subscriber):

const schemaId: DataTrackSchemaId = { name: 'sensor-reading', encoding: 'jsonSchema' };

const definition = await room.localParticipant.getSchema(schemaId, 'publisher-identity');
console.log(JSON.parse(definition));

[changeset-bot]

🦋 Changeset detected

Latest commit: 34b7c29

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
livekit-client	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

size-limit report 📦

Path	Size
dist/livekit-client.esm.mjs	106.8 KB (+0.63% 🔺)
dist/livekit-client.umd.js	115.93 KB (+0.66% 🔺)

[lukasIO]

probably this is too late now, but curious to learn why the success path isn't using the existing RequestResponse format, too

[ladvoc]

Great question, this is because typically a RequestResponse contains a copy of the request. However, in this case, since the request's payload is potentially large, it didn't make sense to echo the whole thing back if there is an error.

[lukasIO]

I know this doesn't really exist as a pattern in this SDK right now, but I'm wondering if we should scope these new methods to a dedicated localParticipant.dataTracks.* namespace so that it's clear what they relate to.

Consistency across SDKs is the biggest factor though, so it ultimately only makes sense if we want to commit to that pattern also for other SDKs.

I find localP.defineSchema sounds a bit too generic to be a data-track only feature.

[ladvoc]

Yes, this is currently what the API looks like in Rust and C++. However, I do like scoping this somehow. Another idea I had is having it under localParticpant.schemaRegistry. I think adoption of this feature is early enough that we could justify marking the current APIs as deprecated and scoping them. For additional context, data blobs support, which is the prerequisite to using this feature, isn't enabled for all projects in cloud yet.