Closed afrind closed 2 months ago
Philosophical question - we now have a N-32 tuple of namespace components and then a track name that hangs off the end. What's the utility in that? Could not the track name just be one of the namespace components?
Can we simplify MOQT by getting rid of the concept of namespace and instead having a N-32 tuple track name?
This is a good start. I am sure we will fix aspects of it as we explore futher, but overall LGTM
It would be good to also bring in the changes proposed in #508
It would be good to also bring in the changes proposed in #508
I will try to take a stab at that but I'm worried the scope is going to blow up this PR, and we'd do better to handle that in a follow up. I mentioned this briefly in the interim, but this PR adds significant functionality that is currently not possible so I am biased towards an iterative approach.
To be clear, I'm happy to land this and then evaluate other improvements like #508 subsequently.
just 2 cents, #508 addresses important design aspects which i feel would be good to consider bringing in this PR as it applies not just to announces but subscribes in general. It would be good to evaulate this PR in the context of #508
Looking at #508 later after lands seems fine to me
I hope we can get agenda time to talk about this one at the next call. This add critical functionally to moq that I would really like to have included even if we still needed time and implementation experience to get all the details sorted.
This message suite allows subscribers to express interest in ANNOUNCE/UNANNOUNCE for set of namespaces that match a prefix. To accomplish safe prefix matching, Track Namesapce is redefined from a single byte array to a N-Tuple of byte arrays.
Fixes #484 Closes #253