Terminology proposal(s)

Resource sounds pretty OK to me. Then we could also have "resource types" and "resource providers"?

I'd say that we use "type" for entity bundles. Really not sure about entity label; title definitely no-go, files use "filename". Maybe we could use "name"?

This is critical as we basically need to define this before we do any real coding.

Resource sounds great, perhaps even go for the more verbose 'media resource'?
Then 'media resource type' sounds correct for the 'media entity types', or 'media type' (perhaps less consistent, but more user-friendly).
For the bundle, i would go for media type, instead of type.
Label could be name, it's nothing more than that, the name of the media-type.
And then media resource type.

I think provider is great name. It provides a media resource type.

Still stuck, on how it all fits together in terminology.

In Scald we are using "type provider", "atom provider", but to make it align with D8, I propose "Media type plugin", "Media resource plugin".

We have two contradictory proposals :

- Philip (Pixelpark) said that each bundle should have only one resource provider (YouTube videos and Vimeo videos don't share the same bundle).
- Yched said that one "video" bundle contains all video resource providers (https://groups.drupal.org/node/327768#comment-969238) - i.e. "the Scald way".

I discussed with Philip just after the Media sprint, and we agreed that we should separate two notions: bundle and type.

- Type provider defines the nature of a media (video, image etc.)
- Bundle is only a subset of resource plugin in a type (for example, we can create a "video1" bundle with videos from YouTube only, a "video2" for videos from both YouTube and Vimeo).

In short: type, bundle, resource plugin.

Our first rule should be to use Drupal terminology correctly. Bundles and Plugins are already used in core and have their exact meaning as such. Bundles are mostly equivalent to content types with nodes, while they apply to all possible entities. Plugins are a concept that was introduced in D8. We're definitely use them, but we should not call anything else like that.

I like proposals by @mallezie. Trying to rephrase
- Individual media entities: Media entity
- Bundles of media entity (analog to content type): Media type
- File and/or asset that individual Media relates to: Media resource
- Type of a resource: Media resource type
- Plugin that provides a given Media resource type to Media entity: Resource provider

Basic question that I see with Media type <-> Resource provider is whether we allow more than one provider per type. I think we should continue that part of the debate in #2100515: Figure out and implement media types.

Well, "resource plugin" and "resource provider" are all short forms of "resource plugin provider". Basically, it is "plugin" (D8 term) of type "Media resouce" (also, D8 term). And the module that provides this plugin is a provider (D8 term, too).

We should not call bundle is whatever type. "Content type" was a mistake (in Drupal 4.6 or Drupal 2 I don't know...) when there was not Entity. Now people are trying to rename "bundle" into "subtype", thus we should not call it "type".

We should not call bundle is whatever type. "Content type" was a mistake (in Drupal 4.6 or Drupal 2 I don't know...) when there was not Entity. Now people are trying to rename "bundle" into "subtype", thus we should not call it "type".

Didn't know about that. Is there any discussion about this that I can check?

#1380720: Rename entity "bundle" to "subtype" in the UI text and help, but I must confess that it won't go anywhere now (postponed to D9). Nevertheless, too many "type" makes me worried.

Interesting. Issue followed. :)

I'd say that we should try to stick with D8 terminology where possible and follow changes if they happen in D9.

Which changes would you make to the proposal in #4?

I'd say:
- Media resource type => Media type
- Media type => Media bundle (and renamed to Media subtype, if that issue were open again, who knows!)

In that way we hide the "resource" layer (those resource fields are only attachable to Media entity and follow a certain logic). In Scald, we are in a special case where media type = media bundle.

Media type is not as same as Entity type nor Node type, but it is a sublime problem. Node type is not Entity type already.

I like those proposals, i wasn't quite sure about the used terminology.

#4 with additions from #9 sounds ok for me too.

So is this correct then?

- media entity
- media bundle (maybe media subtype in the future)
- media type (type of a media resource)
- media resource - file and/or asset that individual media relates to
- media plugin - provides a given media resource type to media bundle

What I don't understand is why do we need media type if we already have media resource in one bundle - isn't this somehow the same or we need media type to say that this media is video, or image, etc?

The case is that you could use the same media type with more media bundles (imagine Youtube media type being used on media bundles "trailers", "music videos", "viral videos", ...) or more media types on one media bundle (Local video files, YouTube videos and Vimeo videos on media bundle "Videos").

Details for this part should probably be tackled in #2100515: Figure out and implement media types.

I'll update issue summary with the latest proposal.

Add issue summary.

But isn't that a bundle actually. Further more if we are attaching media resources to media_entity over fields nothing is stooping as to have one media_entity bundle that handles various media resources (images, videos, what ever...).

Or a type is actually something we use to aggregate different media bundles - for example all video bundles?

Still confused, sorry.

nothing is stooping as to have one media_entity bundle that handles various media resources (images, videos, what ever...)

Field display is configured per bundle, and so is "resource display". A cross media type bundle will complicate the settings page.

Field display is configured per bundle, and so is "resource display". A cross media type bundle will complicate the settings page.

No I meant this. Our media_entity is fieldable. So theoretically nothing is stoping end user over admin UI or code to add additional media_entity resource fields, right? Or we limit this to n - 1 relation?

No I meant this. Our media_entity is fieldable. So theoretically nothing is stoping end user over admin UI or code to add additional media_entity resource fields, right? Or we limit this to n - 1 relation?

I would definitely not limit it. I think that we should build things in a way that would allow multiple "Media types" to be used on a single "Media bundle". Is that what you think?

As I said in the Media sprint, it will be more like "the Asset way". A lot of flexibility with simple fields, but you don't have a good structure for atomic media entity, and there is no standard because it is too flexible. If we go with "the Scald way", then they are not real fields, and only attachable (not technically, but designed to be) to media entities, and are single value fields.

Take an example: a gallery.

- Asset: a Media entity (an empty entity without anything) + a description field + a multiple value image fields, then render it. Most are custom code. The structure is more flexible, but API and customization is less. Also, using Field UI, you can't configure how to display the gallery, how in each item, which preset is use for the thumbnail, for the normal size and full size.

- Scald: a Media entity with an entity reference field (managed by the "gallery provider"), reference to N other Media entities of any type. Less flexible, but more customisable and better API (IMHO).

If a Media entity has 3 image fields and 1 video field, I don't know how to use it. Do you really want to make the whole a "atomic media asset" and link it to a node, or create 4 media entities link them to a node?

I would definitely not limit it. I think that we should build things in a way that would allow multiple "Media types" to be used on a single "Media bundle". Is that what you think?

Yep i was thinking the same exactly, and also i would not introduce this limitation.

As I said in the Media sprint, it will be more like "the Asset way". A lot of flexibility with simple fields, but you don't have a good structure for atomic media entity, and there is no standard because it is too flexible.

Agree on this also, if we want to make it more flexible it will be harder to make core architecture correctly.

But what about this example - I want to create a video gallery. My node is of 'video gallery' type and there I have reference field to media_entity. Now media_entity has a video resource but also I want to have a custom screenshot (not to use screenshot from video provider) which can be handled by local file field. So media_entity will have two fields, one for remote video and one for local screenshot. Now in some future media browser I will have 'media browser' display that renders this media entity inside the browser and one more display for full view.

If we will go with more flexible solution this sounds pretty straightforward to me and this is a case where this two fields should be in one media_entity.

Now the question is if we go with the scald way with more simplified approach how can we handle this or similar use cases?

This discussion should be moved to #2100515: Figure out and implement media types. This issue is about terminology and providers and implementation around them is completely out of scope.

My follow-up comment will follow in that issue.

Updated issue summary.

It seems like we decided about basic terminology. Feel free to reopen if there is anything that was left undefined.