Comparison table of two approaches to media in Drupal.
| Media entity | File entity | |
|---|---|---|
| Pros |
- provides more flexibility - no assumptions about what a media asset is - designed to support various types of media (local, remote, "single value", "mutli value", simple structures - e.g. an image, complex structures - e.g. tweet, playlists, galleries, ...) - solutions with similar approaches already exists in D7 (experience and feedback) - can satisfy almost any possible use case (if not all) - can attract some interest of big media users (which can help funding development) - it's bundles can have semantic meaning, as they're not necessary based on type of media |
- already huge amount of work done - Can fit to any "non-file" use case if you use oEmbed and soluitons like that to handle non-file assets (How many actual implementations of this approach are out there? Are there any case studies, etc.?) - Only one layer to handle assets : File Entity (simpler architecture) |
| Cons |
- adds another layer of abstraction (more complex architecture; speciall for devs) - needs implementation from scratch (mitigated by the fact that we have very good Entity API in D8 and that all other solutions also need to do non-trivial D8 ports) |
- assumes what an asset is - does not support complex media assets (e.g. media gallery that includes mulitple images/videos) - data structure that File entity uses (file_managed table) was created with local files only in mind, which causes problems for non-local files use cases - bundles are defined based on mime type, which is limiting - have problems satisfying all needs of big media companies/sites - experienced problems with pace of development and funding in the past (not a technical problem, but definitely something that needs to be fixed) |
Comments
does not support complex
oEmbed is the perfect use case for this. Not sure why it's a con for file_entity.
What problems? I'm not aware of what this is referring to.
Opinion, not fact.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
All of this pros and cons are
All of this pros and cons are extracted from debate in https://groups.drupal.org/node/384813. That is the place where things should be discussed as all of the items that appeared here were.
If you believe that we missed something here please engage in the discussion there and present real arguments that you think will help change people's opinions.
I'm still waiting for some feedback about oEmbed (see below), while you definitely didn't manage to convince me your way about the other two yet (lots of points and arguments already expressed in the discussion to back my belief).
<
blockquote>oEmbed is the perfect use case for this. Not sure why it's a con for file_entity.
oEmbed is a 3rd party solution and not part of File entity. Also (2nd and 3rd paragraph): https://groups.drupal.org/node/384813#comment-999403
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name
The File Entity and Media for
The File Entity and Media for D7 modules have managed to work pretty well with the oEmbed module and supporting anything that oEmbed supports as files and in the media browser.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
You are calling for
You are calling for compartmentalized functionality- the fact that oembed is a third party module points to exactly the kind of ecosystem you want to see.
http://24b6.net
Need clarification/correction
From the file entity con list:
- assumes what an asset is This isn't true- file entity just stores a URI- there is not assumption about what the thing is which is a strength of the stream wrapper approach
- does not support complex media assets (e.g. media gallery that includes mulitple images/videos) This depends on what the URI references. File entity does not limit this, providers do. The con might be "limited number of providers" There are attempts in the media module to handle this- https://drupal.org/project/media_node is an example
- data structure that File entity uses (file_managed table) was created with local files only in mind, which causes problems for non-local files use cases The file managed table stores URIs- why is this considered local?
http://24b6.net
I'd really like to keep the
I'd really like to keep the discussion in one place (i.e. https://groups.drupal.org/node/384813). Please feel more than welcome to update wiki, but please keep discussing there.
We could link from pro/con items to places (comment in discussion thread, etc.) where that specific feature is discussed, to make things more transparent.
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name