An Islandora without Fedora

[mjordan]

This is a meta-issue for discussion around what not using a Fedora back end in an Islandora 8 repository means. So far, we have mentioned this possibility in the following issues:

• Explore possibility of a Fedora-less CLAW #945
• Houdini has dependency on Fedora #1067

and there may be others. It's also mentioned in the new user documentation, where we cite the following value-adds that Fedora brings to Islandora:

• flexible, and configurable, disk storage architecture
• fixity digest generation
• Memento versioning
• integration with RDF/Linked Data triplestores
• Integration with Microservices via API-X
• WebAC Policies for access control

The purpose of this issue its not to develop an argument for excluding Fedora from all Islandora repositories, but to discuss the relative advantages and disadvantages of using Fedora (the points above being straw men for the advantages) and also to offer clear advice to repository managers for choosing not to use Fedora (assuming the standard configuration is to use it).

[bryjbrown]

The purpose of this issue its not to develop an argument for excluding Fedora from all Islandora repositories, but to discuss the relative advantages and disadvantages of using Fedora...

I'd further qualify this statement by adding "...in the context of differing use cases". I think I've been careless with my language in a few situations in the past and appeared to speak about "the disadvantages" of Fedora as if they were objective statements of fact instead of subjective statements in relation to Florida State University's use case, and for that I apologize.

With that in mind, the primary disadvantage in the context of FSU's use case is maintainability from an operations perspective. The added complexity of Fedora & Camel is beyond the capabilities of our staff, in fact we are currently reconsidering the inclusion of ALL applications external to Drupal in our repository solution that complicate deployment and maintenance (for example, Drupal 8's Search API allows you to do a lot of things via the database server you are already running as opposed to running a separate Solr instance). From that perspective, its not so much about whether we want to run Fedora 4 or not, we simply aren't able to in our current context. We are trying to find a way to run a repository solution that is cheap and simple enough not to require more resources (both monetary and human) than what we have, while still being flexible to meet our needs and potential needs we might find in the future. Our current efforts towards this are to see how far core Drupal 8 plus existing community modules takes us (we're still discussing Matomo and triplestore integration as options, but only if necessary).

Obviously the use case I have described for FSU isn't for everyone; we are trying to find the simplest solution that can scale up while the CLAW project has had a very different charge. What I'd like to see come out of this conversation is where we can overlap. Obviously we'd love to be able to use as much Islandora infrastructure (and contribute back) as possible, but this will only be possible if we proceed with development with loose coupling in mind; instead of assuming that Fedora will always be available when building Islandora 8.x code, keep in mind ways that things could be done at the Drupal level when possible, and if Fedora is absolutely required for a feature, include it in a way that doesn't make the module unusable if Fedora isn't available. As a thought experiment, you could imagine a theoretical module called islandora_fedora or something similar that contains ALL of the functionality related directly to Fedora, and the rest of the Islandora codebase would operate in the same way whether that module was installed or not.

Perhaps I'm really stepping in it with this wall of text, but I think these are important questions that we should explore that are going to have big implications for what our community means moving forward.

[dannylamb]

@bryjbrown So from the start we've wanted Islandora 8 have a "take what you want and only that" aspect to it underneath the "turn key repository solution" angle that we've always played. I think the FSU use case is really testing that in an extreme way, which is unsurprisingly surfacing issues.

We already have submodules in islandora, and islandora_fedora is totally do-able and in line with precedent. It goes further, though. There's other stuff that assumes you have some sort of messaging broker set up, and that would have to get nested into a submodule, too. Wouldn't be a bad idea to split out our context stuff and the rest api too. I mean really, attempting this use case will brutally test the granularity we've striven to achieve. But in the end that will for sure make cleaner and more usable modules.

And if you want to get philosophical about it, if you strip out everything that isn't a Drupal module, I think you'd definitely have something that's still an Islandora. You'd still have an object model (which is roughly analagous to 7's), a rest api for that object model, shared vocabularies, viewers, the Context system, etc... There's still lots of overlap there with anyone trying to build a repository with Drupal. And there is simply no reason why someone doing that should be excluded from using Islandora modules and potentially contributing back. Total buy-in can be a turn off, and if you have no need for a scalable audio derivative server, then why should you be forced to run one?

[mjordan]

Maybe we should list the functionality of core Islandora as it exists in the upcoming 1.0 that assumes Fedora is present. This list is not correct or complete, so please jump in and edit this table if you can. If you can't, list items in comments and we can consolidate later.

Currently (1.0) assumes Fedora	Current (1.0) impact of not using Fedora
message broker	?
triplestore	?
derivative creation via microservices	?

[dannylamb]

@mjordan Without Fedora, you'd lose

• Assets served over LDP
• Fixity digest generation
• Audit trail
• Memento versioning (e.g. Wayback Machine compatibility)
• Api-X, which advertises relevant micro services for repository content
• And even though it's pending Fedora 6, OCFL. I think is a big step in a good direction for Fedora and a transparent file system for the repository sits well with a lot of folks

[mjordan]

@dannylamb right, OCLF is a major benefit. I can imagine OCFL could be implemented on the Drupal public file system, for example, but the amount of work that would take would be crazy.