search

lbryio / types

Cross-language definitions for standard LBRY types
8 stars 9 forks source link

added image and audio #28

Closed eukreign closed 5 years ago

lyoshenka commented 5 years ago

the Image/Audio/Video oneOf seems wrong to me. we should have a place to put visual properties (height, width) and a place to put time properties (duration) as just separate things. Then anything with a height and a width can set its height and width. And anything with a duration can set its duration. There's no need to say "this is an image"

lyoshenka commented 5 years ago

and furthermore, it would be good to think for tomorrow here before we get too sucked into adding all these fields. taxonomies are hard, and we're not the first people to make one. lets find one that exists and see what we can learn from how they do it.

lyoshenka commented 5 years ago

finally, i'm not sure why you renumbered so many of those fields. the only thing that matters about the number "is it over 16 or not". the order of the fields does not matter, the specific number does not matter, etc.

eukreign commented 5 years ago

I've spent a little bit of time researching this and was not able to find any established file meta data taxonomy. I imagine that if something like this was possible someone would have done it...

It's hard to build a taxonomy without having an existing system to dissect into possible taxonomy groups, etc.

Can we keep v2 of protobufs as simple buckets for file types and later once we've collected an adequate amount of types we can slice them up into attribute groups and do a v3 of protobufs?

Regarding the renumbered fields, I made the Channel and Stream messages group similar attributes together so that it's easy to see what's different and what's the same between them. I renumbered them for the exact reason you mention, that it doesn't really matter sub-16 and seems strange having them out of order.

eukreign commented 5 years ago

I'm thinking of the taxonomy problem as taking a single table data model and normalizing it into more logical sub-tables except that in our case, we're starting with a blank slate and are trying to start with a normalized model. I think it's going to be unnecessarily difficult to do it. It would be better and more efficient to first make a simple non-normalized meta data model and then later once we have the full model, go back and normalize it.