Allow users to specify what is "In the repository"

[dannylamb]

a.k.a. the solution to "what is an islandora 8 object anyway"

This has been discussed in user calls, Islandora 8 calls, and a handful of special topic calls. I think the solution that we're looking for exists, and, in fact, we've been doing it all along.

Right now, we ask users to specify which content types, media types, and taxonomy vocabularies they want the Fedora URI to automagically appear for. This is a specific example of wanting specialized behaviour around what is "in the repository", and in order to make it happen, we check that configuration and do stuff. What I'm proposing we do is keep this in the main Islandora 8 config form, but rebrand it so we're letting users declare what the Islandora types are.

Then the "In the repository" condition can be used with context and it will simply check against the types the user specifies. We actually pondered this implementation when doing the original work to show the Fedora URI and felt it was overkill at the time. But I'm pretty sure the time is now, and most everyone can agree given the configurable nature of Islandora 8, letting the user specify is the only sane path forward. If we can formalize this, then we can refactor things to use it, and also start considering more sophisticated UI changes in order to improve UX.

[dannylamb]

@rosiel gonna need your blessing before I start on this

[seth-shaw-unlv]

As mentioned on the tech call just now, some of our image media are indexed in the repository, while others aren't. E.g. we have a picture of the reading room used for a blog post. It is an image media but not something we want pushed to Fedora.

[rosiel]

We've had a lot of community based discussion and the idea that we could dictate this at the bundle level, for both media and nodes, gained a lot of traction. This would increase the ability to manage, get reports of what's 'in the repo', and make it more transparent to people making content, what they're doing.

If individual entity-lefvel overrides are something that you need (as seems to be implied), can that be implemented as a hookable plugin, rather than shutting down a solution that makes sense to most people?

As Danny pointed out recently, each Media bundle uses one MediaSourceInterface. https://api.drupal.org/api/drupal/core%21modules%21media%21src%21MediaSourceInterface.php/interface/MediaSourceInterface/8.7.x A MediaSourceInterface is responsible for "Defining how media is represented (stored)" as well as validation, thumbnails, and appropriate metadata. That seems (to me!) like its intention (which can be overridden through flysystem but in my opinion that defeats the premise of a MediaSourceInterface) is that files in different storage locations ("local" and "remote" being the most evident ones, as given in examples in that documentation) can have their own MediaSourceInterface objects. And therefore, this would mean, unlike what you're doing (which is a cool workaround! don't get me wrong!) having two different types of media for things that are in/out of Fedora.

[seth-shaw-unlv]

For a point of clarification I'll note that the MediaSourceInterface implementations are not bound to the Media bundles, but rather the file fields the bundle uses. E.g. with multi-media file you could actually be using multiple implementations of MediaSourceInterface (such as VideoFile for the video and File for the transcription). All the ones we use are or extend File (which then can be used with Flysystem) whereas the 'remote' versions use OEmbed. File already allowed multiple storage locations (public and private filesystems). Flysystem doesn't override this, but instead extends the available locations to store content. So, the statement in the documentation about this class doesn't really apply to the "Bundle as Islandora Object component" question.

All that aside, I concede that the idea of "islandora-ness" could be simplified by creating "Islandora"-specific Media bundles. It could potentially make theming a bit more of a pain (there will probably be a number of twig templates that need to be extended to have a consistent "Image" display for both Islandora and non-Islandora media), but we can live with it.

[alxp]

I think what's more instructive about how Media is done in Drupal and the Lightning distro in particular, is that it doesn't try to make one media do different things even if they seem alike.

Best example is that they separate out Video from Audio, and Local Video from Remote Video. It's tempting to try and make one content type to rule them all for the sake of Don't Repeat Yourself, but I think the aim to simplify the individual types is more compelling. If you try to make a content type perform multiple duties, you mostly just end up with a lot of case statements in every function to handle each type.

So I think trying to collapsee multiple purposes in one media type is not something I'd want to try and do.

+1 for special purpose Islandora media types.