MediaTypeRefactor: Difference between revisions
(Created page with "We're planning to extend the media type system so that it's more like plugins. This page is to document some of the things we wish media types to be able to accomplish. == A...") |
No edit summary |
||
| Line 4: | Line 4: | ||
In feeds and etc, we want to share the mimetype of the entry, and maybe of the individual files? Should this be on a per-entry or a per-filetype basis? |
In feeds and etc, we want to share the mimetype of the entry, and maybe of the individual files? Should this be on a per-entry or a per-filetype basis? |
||
== Additional field types == |
|||
===File size=== |
|||
For MRSS atom feeds (and probably also in the media "home" page, we need the file size of the media. Currently it is not stored at all. spaetz has a branch that implements a MediaEntry().file_size property. This works OK with local storages as it pulls the files and gets the file size on demand. But on remote storages (Amazon S3), we don't want to pull all files just to create the atom feed. We will therefore need to store the file size for each main media. Should this simply become part of the main MediaEntry table? Should it be part of an "extended Media Entry" table that is only queried on demand? I guess as we need this for all file types, so it does not make sense to put it in the per-type meta data table... |
|||
Revision as of 14:36, 22 November 2012
We're planning to extend the media type system so that it's more like plugins. This page is to document some of the things we wish media types to be able to accomplish.
Accurately describe mimetype
In feeds and etc, we want to share the mimetype of the entry, and maybe of the individual files? Should this be on a per-entry or a per-filetype basis?
Additional field types
File size
For MRSS atom feeds (and probably also in the media "home" page, we need the file size of the media. Currently it is not stored at all. spaetz has a branch that implements a MediaEntry().file_size property. This works OK with local storages as it pulls the files and gets the file size on demand. But on remote storages (Amazon S3), we don't want to pull all files just to create the atom feed. We will therefore need to store the file size for each main media. Should this simply become part of the main MediaEntry table? Should it be part of an "extended Media Entry" table that is only queried on demand? I guess as we need this for all file types, so it does not make sense to put it in the per-type meta data table...