Move media type strings to constants and use a content type lookup util #882

New issue

Closed

opened 2019-01-26 00:29:13 +01:00 by jessopb · 1 comment

jessopb commented

2019-01-26 00:29:13 +01:00

(Migrated from github.com)

The code is littered with tests for 'image/gif', or determinetype() or extension for 'type/ext'.
Adding a new type support involves editing many files consistently.
This should be centralized.

Dev can add a file type to publish capabilities by adding a content type to centralized location
Dev can add a file type to preview or show by adding a content type to centralized location
Dev can choose a viewer by category: IMAGE, TEXT, DOCUMENT, 3D, VIDEO.
Admin can enable or disable types in config
Admin can set file size limits with variable granularity.
Do we need variable limits for "image" (gif different from jpg)?

The code is littered with tests for 'image/gif', or determinetype() or extension for 'type/ext'. Adding a new type support involves editing many files consistently. This should be centralized. - [ ] Dev can add a file type to publish capabilities by adding a content type to centralized location - [ ] Dev can add a file type to preview or show by adding a content type to centralized location - [ ] Dev can choose a viewer by category: IMAGE, TEXT, DOCUMENT, 3D, VIDEO. - [x] Admin can enable or disable types in config - [x] Admin can set file size limits with variable granularity. - Do we need variable limits for "image" (gif different from jpg)?

kauffj commented

2019-01-28 20:32:36 +01:00

(Migrated from github.com)

I endorse cleaning this up on the path to filtering and/or as you're adding support for more types.

It seems decently likely that we'll want a file to carry around both it's media type and a higher-level category (like "image", "text" as you say).

If we need content-specific file size limit, I'd guess that category-based would be sufficient. However, if this adds any substantial complexity, I think a single global limit is fine.

I endorse cleaning this up on the path to filtering and/or as you're adding support for more types. It seems decently likely that we'll want a file to carry around both it's media type and a higher-level category (like "image", "text" as you say). If we need content-specific file size limit, I'd guess that category-based would be sufficient. However, if this adds any substantial complexity, I think a single global limit is fine.

This discussion has been locked. Commenting is limited to contributors.

No milestone

No project

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/spee.ch#882

No description provided.

Rows
Columns