Simplify naming by removing the distinction between Track Namespace and Track Name

[wilaw]

Alan's PR #498 introduced a N-tuple construct for namespace, in which the namespace is made up of an ordered sequence of between 1 - 32 byte arrays. This allows us to construct namespaces in the form

example.com meeting abc123 alice

Alice would publish tracks under this namespace called audio|video|catalog leading to the final track identifiers being

example.com meeting abc123 alice audio
example.com meeting abc123 alice video
example.com meeting abc123 alice catalog

At this point, the distinction between the track name and last stanza of the namespace is arbitrary and I would argue, unnecessary.

We could remove the separate concepts of TRACK-NAMESPACE and TRACK-NAME and instead coalesce this down to a single construct of TRACK-NAME, which would hold the same definition as a bounded N-tuple. So under the simplified scheme, the TRACK-NAMES would be

example.com meeting abc123 alice audio
example.com meeting abc123 alice video
example.com meeting abc123 alice catalog

Alice as the publisher would ANNOUNCE the minimum prefix which uniquely describes describes the content she is responsible for, in this case, she would announce

example.com meeting abc123 alice

This schema then allows for easy aggregate subscription. We could remove the need for SUBSCRIBE-NAMESPACE. For example, a subscriber wanting to receive everything produced by Alice would SUBSCRIBE to

example.com meeting abc123 alice

Someone wanting to receive all feeds from meeting abc123 would SUBSCRIBE to

example.com meeting abc123

If we standardize some means of communicating a null (*) stanza, and if different publishers produced

example.com meeting abc123
statistics.com metrics abc123

the someone wanting both the meeting and metrics for abc123 could SUBSCRIBE to

abc123

[suhasHere]

I generally like the suggestion here except the last <null> <null> abc123. If we allow nulls or (.*) regex parsing in between , it just makes things pretty slow. We can start with prefix matching to begin with and see if we need to add more flexibility ?

[alvestrand]

Having complete names from the name root to the tree node you want to point to is usually a Good Thing (experience with DNS searchpaths). If nulls were allowed, subscribing to "foo" would result in "mallory foo" popping up in your feed when you just wanted to listen to "alice foo" and "bob foo", with no knowledge ahead of time that Mallory existed.

…

On Fri, Aug 23, 2024 at 11:54 PM Suhas Nandakumar ***@***.***> wrote: I generally like the suggestion here except the last abc123. If we allow nulls or (.*) regex parsing in between , it just makes things pretty slow. We can start with prefix matching to begin with, — Reply to this email directly, view it on GitHub <#508 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADVM7LXRN6XHGXUTUYLHU3ZS6VR3AVCNFSM6AAAAABNAAPHZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBXHA2TOOBYGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[suhasHere]

Having complete names from the name root to the tree node you want to point to is usually a Good Thing (experience with DNS searchpaths).

+1

[ianswett]

I started working on a PR to do a simple version of this that merged the two fields, and it was more invasive than I was expecting. One question is what to call the new single field. "Track Name" or "Full Track Name"?

[wilaw]

One question is what to call the new single field. "Track Name" or "Full Track Name"?

Just "Track name". There is no longer any notion of "full".