LBRYCommunity/types
1
0
Fork 0
Code Issues 13 Pull requests Packages Projects Releases Wiki Activity

added image and audio #28

Merged
eukreign merged 10 commits from stream_sub_types into master 2019-03-31 15:01:40 +02:00
Conversation 5 Commits 10 Files changed 6 +17322 -3915
eukreign commented 2019-03-25 15:55:46 +01:00 (Migrated from github.com)
Copy link
No description provided.
lyoshenka commented 2019-03-25 17:47:31 +01:00 (Migrated from github.com)
Copy link

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"

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 2019-03-25 17:48:14 +01:00 (Migrated from github.com)
Copy link

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.

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 2019-03-25 17:49:24 +01:00 (Migrated from github.com)
Copy link

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.

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 2019-03-25 21:20:33 +01:00 (Migrated from github.com)
Copy link

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.

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 2019-03-25 21:39:54 +01:00 (Migrated from github.com)
Copy link

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.

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.
kauffj (Migrated from github.com) reviewed 2019-03-28 16:00:23 +01:00
v2/proto/claim.proto
kauffj (Migrated from github.com) commented 2019-03-28 15:53:59 +01:00
Copy link

Is 1 BTC (deprecated)?

Is 1 BTC (deprecated)?
v2/proto/claim.proto
@ -20,3 +22,1 @@
string thumbnail_url = 16;
string cover_url = 17;
string language = 18;
string contact_email = 8;
kauffj (Migrated from github.com) commented 2019-03-28 15:59:37 +01:00
Copy link

Does a repeated language field mean this content is in both languages or either language?

Do we have an idea of how we'll (eventually) support the same claim being in 8 different languages with 8 different files? Is it compatible with this choice?

Does a repeated language field mean this content is in both languages or either language? Do we have an idea of how we'll (eventually) support the same claim being in 8 different languages with 8 different files? Is it compatible with this choice?
v2/proto/claim.proto
@ -55,3 +65,4 @@
message File {
bytes hash = 3;
string name = 1;
uint64 size = 2;
kauffj (Migrated from github.com) commented 2019-03-28 15:53:25 +01:00
Copy link

If we're adding these in this PR then I think we should add everything we're targeting first-class support for. Off the top of my head, games, text/markdown, pdf, and maker/3d file types are not on the list.

Also, is there any way to have types map media_type on to this type without a discrete field?

If we're adding these in this PR then I think we should add everything we're targeting first-class support for. Off the top of my head, games, text/markdown, pdf, and maker/3d file types are not on the list. Also, is there any way to have `types` map `media_type` on to this type without a discrete field?
v2/proto/claim.proto
@ -63,0 +94,4 @@
UNKNOWN_LANGUAGE = 0;
en = 1;
aa = 2;
ab = 3;
kauffj (Migrated from github.com) commented 2019-03-28 15:57:36 +01:00
Copy link

I can think of a number of additional fields for all of these. How deep do we want to be going on this right now vs. evolving it?

I can think of a number of additional fields for all of these. How deep do we want to be going on this right now vs. evolving it?
eukreign (Migrated from github.com) reviewed 2019-03-28 21:01:36 +01:00
v2/proto/claim.proto
@ -55,3 +65,4 @@
message File {
bytes hash = 3;
string name = 1;
uint64 size = 2;
eukreign (Migrated from github.com) commented 2019-03-28 21:01:35 +01:00
Copy link

The type is mainly to store extra metadata; not as a way to determine the type of the stream. When there is metadata, this metadata is typed, hence the field is called type (as opposed to a un-typed dictionary of key, values).

media_type is still the correct way to determine the file specific type of a stream.

The `type` is mainly to store extra metadata; not as a way to determine the type of the stream. When there is metadata, this metadata is typed, hence the field is called `type` (as opposed to a un-typed dictionary of key, values). `media_type` is still the correct way to determine the file specific type of a stream.
eukreign (Migrated from github.com) reviewed 2019-03-28 21:05:29 +01:00
v2/proto/claim.proto
eukreign (Migrated from github.com) commented 2019-03-28 21:05:29 +01:00
Copy link

I don't know why BTC was dropped. It was already gone from v2 protobufs when I started integrated them.

I don't know why BTC was dropped. It was already gone from v2 protobufs when I started integrated them.
eukreign (Migrated from github.com) reviewed 2019-03-28 21:09:29 +01:00
v2/proto/claim.proto
@ -63,0 +94,4 @@
UNKNOWN_LANGUAGE = 0;
en = 1;
aa = 2;
ab = 3;
eukreign (Migrated from github.com) commented 2019-03-28 21:09:29 +01:00
Copy link

We can add more now or hold off and add more in the next release. I don't think it makes a difference (unless there is a field someone is waiting to have added, then we can add it now).

We can add more now or hold off and add more in the next release. I don't think it makes a difference (unless there is a field someone is waiting to have added, then we can add it now).
eukreign (Migrated from github.com) reviewed 2019-03-28 21:27:53 +01:00
v2/proto/claim.proto
@ -20,3 +22,1 @@
string thumbnail_url = 16;
string cover_url = 17;
string language = 18;
string contact_email = 8;
eukreign (Migrated from github.com) commented 2019-03-28 21:27:53 +01:00
Copy link

I imagine that the languages and locations lists are specific to the content in the particular stream claim.

Since channels also have languages you could release a movie in multiple languages by making a channel for it (listing all languages in the channel metadata) then publish a version of the movie in those languages in that channel (and list only the single language in the stream claim).

Perhaps channels within channels could also help here.

I imagine that the languages and locations lists are specific to the content in the particular stream claim. Since channels also have `languages` you could release a movie in multiple languages by making a channel for it (listing all languages in the channel metadata) then publish a version of the movie in those languages in that channel (and list only the single language in the stream claim). Perhaps channels within channels could also help here.
eukreign (Migrated from github.com) reviewed 2019-03-29 14:28:03 +01:00
v2/proto/claim.proto
eukreign (Migrated from github.com) commented 2019-03-29 14:28:02 +01:00
Copy link

Re-added BTC.

Re-added `BTC`.
lyoshenka (Migrated from github.com) reviewed 2019-03-29 14:48:51 +01:00
v2/proto/claim.proto
@ -60,3 +76,4 @@
message Video {
uint32 width = 1;
uint32 height = 2;
uint32 duration = 3;
lyoshenka (Migrated from github.com) commented 2019-03-29 14:48:51 +01:00
Copy link

@eukreign why have an unknown currency option? whats the point of a claim with a fee in a currency we don't know?

@eukreign why have an unknown currency option? whats the point of a claim with a fee in a currency we don't know?
lyoshenka (Migrated from github.com) reviewed 2019-03-29 14:50:24 +01:00
v2/proto/claim.proto
@ -63,0 +117,4 @@
bs = 23;
ca = 24;
ce = 25;
ch = 26;
lyoshenka (Migrated from github.com) commented 2019-03-29 14:50:23 +01:00
Copy link

1 - all these UNKNOWN_* fields don't make sense. if its unknown, just leave it out
2 - common languages should go into the top 15. helps reduce the size.

1 - all these `UNKNOWN_*` fields don't make sense. if its unknown, just leave it out 2 - common languages should go into the top 15. helps reduce the size.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
area: devops

   
area: discovery

   
area: docs

   
area: livestream

   
area: proposal

Work is part of a proposal

  
consider soon

Discuss this issue at the next planning meeting, then remove this label

  
Epic

   
good first issue

   
hacktoberfest

Welcome to Hacktoberfest

  
help wanted

   
icebox

Long-term storage

  
level: 1

No knowledge of the existing code required

  
level: 2

Some knowledge of the existing code is recommended

  
level: 3

Significant knowledge of the existing code is recommended

  
level: 4

Intimate knowledge of the existing code is recommended

  
needs: exploration

Solution unclear, needs research

  
needs: grooming

Issue needs to be groomed before work can start

  
needs: priority

Priority level needs to be defined

  
needs: repro

Issue needs step-by-step instructions on how to reproduce in latest code

  
needs: tech design

Needs technical design signoff before implementation can begin

  
on hold

Temporarily paused

  
priority: blocker

Issue is blocking release, do ASAP

  
priority: high

Work needs to be moved into sprint ASAP

  
priority: low

Work should be done but can stay in the backlog for now

  
priority: medium

Work needs to be done within 2-3 sprints

  
resilience

   
Tom's Wishlist

   
type: bug

Existing functionality is wrong or broken

  
type: discussion

A conversation. No specific changes requested

  
type: improvement

Existing (or partially existing) functionality needs to be changed

  
type: new feature

New functionality that does not exist yet

  
type: refactor

Minimal user-visible changes, but significant internal work

  
type: task

Either work that's not related to the code, or a small chore that does not fit into other categories

  
type: testing

Solution needs additional user testing

  
unplanned

Work that was not planned into the spirnt, took priority over planned work

No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
Epic
good first issue
hacktoberfest
help wanted
icebox
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/types#28
No description provided.
Delete branch "stream_sub_types"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?