Add support for filtering by file type #111
Labels
No labels
area: app c
area: app d
area: devops
area: discovery
area: docs
area: proposal
area: X-device Sync
Chainquery
consider soon
dependencies
Epic
Fix till next release
good first issue
hacktoberfest
help wanted
icebox
Invalid
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
Parked
priority: blocker
priority: high
priority: low
priority: medium
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lighthouse.js#111
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
I believe this involves the following:
Reading the file's content type into the elastic search document. We currently store the file's media type (mime type) in the content_type column on a claim.
Creating a mapping between mime/media types and more usable file types. While it's fine/good to support direct querying by media type, it is more useful to search by a generic type. So "video" might correspond to
video/mp4,video/x-msvideo, etc.Some suggested first types are: video, audio, written, CAD, archive
Presumably, these human readable types should not be written to the document, instead the API can map/unmap these more usable terms in business logic.
Acceptance Criteria
Definition of Done
@tiger5226 and @filipnyquist first we need a basic triage, is this issue workable/doable? What else do we need to know? Do you(either one or both) want to do it? There is a community member who may be interested, is this issue suitable for that situation?
We need to either:
Thoughts?
@alyssaoc We need to to know the precise mappings referenced by @kauffj. As long as how we do this is up to do us, this should be enough information to complete the issue.
As for a new person tackling this, is this what we want? Why not have @filipnyquist or I work on it?
@tiger5226 That is choice one, either one of you works on it. If you want to pass, you can, just confirm that it is workable. It opens up a lot of other development opportunities and is important but not urgent.
I'm fine with anyone doing it. I believe @filipnyquist is expected to be unavailable for a few weeks as he is beginning university.
The background here is that I encouraged @jamesbiller to seek out a technical contributor who was familiar with maker (3d printing and more) use-cases. After some discussion, we realized that a lot of desired directions are blocked by this issue, like the ability to construct views that only show CAD content. Additionally, since I consider pursuing this domain to be in the experimental area, I'm hesitant to dedicate significant amounts of core contributor time to maker-specific issues. However, this feature is clearly of broad and general benefit, so I don't think that applies here.
So basically the options are:
Regarding creating the file type mappings, I think my initial list is a fine start. The engineer working on this should construct the specific mime type list.
@kauffj All clear! I will put this on my list. I run into situations sometimes where I am temporarily out of work for milestones and I pick from the queue. I like to have a secondary queue to fallback on. Right now that is api-forms ( did some more work there last weekend), chainquery, and lighthouse. So this is actually perfect for that fall back queue when I need to wait for responses or new issues.
merged and deployed with #144