MediaTypeRefactor

NOTE: A good portion of this page is out of date, because media types now *are* plugins.

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.

See also: Feature_Ideas/Reprocessing

Feature ideas / use cases

Dumping some feature ideas that could affect the design of this here, but don't actually describe how they'd be implemented necessarily.

File "History"

What if we would like files to have something like "design hub", where you can upload revisions of a project as you go along:

https://mairin.wordpress.com/2010/03/09/another-design-hub-mockup/

media-type-specific views

Maybe your media type benefits from submitting or adjusting some extra things after the fact?

Maybe your media type has a "special type of gallery", for example an audio playlist?

submitting media from the command line

Submission is very tied to the submit view. What if someone wanted a tool like:

 ./bin/gmg submitmedia moognu.gif

(How would this work also if plugins add extra things to the submit process though?)

supertypes of images (raw files)

Raw files are also images. They'd have all the usual JPEG variants plus the extra raw file. (The raw file could be connected as attachment though)

multiple renders of the same source

E.g. video: 240p, 360p, 480p, 640p, 720p, 1080p, WebM, x264, etc.

separation between originals and renderers

One of the files is special, because you can make every other asset from that one. It could make sense to split file storage from these cached files. In case you want to have the cached ones on volatile but fast storage for frequent access, and the originals on cheaper/more reliant/slower storage where they'd still be accesible, just not as much.

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... Elrond says: I think, we should have filesizes stored in the MedaFiles table. Because each resolution has its own filesize.

Mime type

Feeds etc need to be able to specify the mime type of a media file. Currently there is no way to get at the file's mime type. We'll need to think whether we store this per-file, simply in an extra field, or in an extra MimeType table? Or...?

 16:13 < Elrond> We had a discussion on mimetype detection from bytes:
 16:13 < Elrond> >>> import magic; ms = magic.open(magic.MAGIC_MIME_TYPE); ms.load(); 
                 ms.file("really_a_jpg.png")
 16:13 < Elrond> 'image/jpeg'
 16:14 < Elrond> Works also:
 16:14 < Elrond> >>> ms.buffer(file("really_a_jpg.png").read(20))
 16:14 < Elrond> 'image/jpeg'