Skip to content

November 4, 2015

Jump to bottom Edit New page
Nick Ruest edited this page Nov 4, 2015 · 12 revisions

Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:

Attendees

  • Nick Ruest
  • Danny Lamb
  • Melissa Anez ⭐
  • Diego Pino
  • Donald Moses
  • Lingling Jiang
  • Diego Pino
  • Andrew Woods
  • Jared Whiklo
  • Kelli Babcock
  • Kevin Bowrin
  • Paul Cummins
  • Brad Spry
  • Sunny Lee

Agenda

  1. GitHub shuffle
  2. Sprint Updates
  3. Updating Karaf -- see: https://github.com/Islandora-Labs/islandora/issues/57#issuecomment-153082525
  • Leads to question, do we want to accept multipart/form-data directly from Drupal? Should we not be exposing transactionality and provide a more appropriate rest api based on rdf and pcdm? Shouldn't Drupal be responsible for converting it's own format into RDF?
  1. Talk about how if splitting pcdm:Objects into multiple Drupal entities could be a solution / API rethinking.
    • http://irclogs.islandora.ca/2015-11-04.html
    • EFQ, Bundles, how to abstract as granular as possible an Islandora Object
    • This could help to:
      • Allow Drupal management of permissions of resources inside each pcdm:Object
      • Update parts individually
      • Manage derivative workflow
      • Smaller messages
    • Would need a LDP services. Handle everything at drupal side as pcdm, let camel transform back and forth
    • Lost's of issues, questions.
  2. Tickets

Minutes

  1. Github shuffle - Islandora Roadmap voted to move the 7.x-2.x project to its own github org and give it a new codename: Islandora CLAW. A backronym for CLAW Linked Asset WebFramework.

  2. Sprint updates - first 7.x-2.x community sprint is underway. Danny and Nick did a live demo on Monday and recorded it. This is not a sprint where we expect to get much or any code written. It's more important to get the community up to speed on the new project and building an environment for discussion and to create issues. Many of the active tickets are for user documentation. There are also some tickets being worked through on the dev branch

  3. Karaf - one simple thing that is holding up a lot of other things. We should upgrade from karaf 3 to 4, which we need because it has better toys (plus using latest version is best practice). But this causes an issue with jetty component and it will not handle multi-part messages. So updating breaks basic Image. But we need to update. But that breaks Basic Image. As result we should talk about the API - should RDF be created on the Drupal side? Add the image file and then commit the transaction. Danny not not want to make such a major change without consultation.

  • Are we comfortable with having an API that is meant to serve RDF and is granular, versus sending everything over from Drupal in a blog and having the middle layer handle it appropriately. We are going to have this conversation about a lot of different things: it all comes down to "where is the best place to handles things?" All in Drupal? All outside of Drupal? Happy middle?

  • Maybe we can start by finding a solution with what we have and work on the bug with jetty. When we are done with that we can move to the next step. At some point we will need some kind of multi-part message handler.

  • Kevin: Why not talk to f4 directly and have camel pick up the changes in f4?

  • DannyL: The idea is to pull as much out of Drupal possible to have a centralized REST API interacting with Fedora instead of doing it directly on the Drupal filesystem.

  • Jared: so Drupal outputs RDF, but we need to make PCDM and send that to Fedora. Or that is my understanding

  • How does the current stack do this? DL Answer: it handles it directly and it waits. Islandora core and Tuque.

  • Is Drupal potentially going to be a bottleneck: DL Answer: Not likely. Our main bottleneck is trying to do large derivatives on the web server. CLAW is addressing this with de-coupling and asychronicity.

  • Kevin: We need to be careful to make it clear what is and is not done by Drupal. As development continues, it will be tempting to do more of the development in php in Drupal modules. Danny: Great point. We are still trying to figure out where that line of delineation is.

  • For now, Diego's suggestion seems like the best way. Find a way to fix the current upstream problem, and keep talking about the API and how it relates to PCDM and what we want that to look like.Eventually Collection and Basic Image will be rewritten. Switching from Spring DSL to Java DSL will make this fix easier. Jared is working on it.

  1. API change ideas (listserv reference) - right now we are putting a whole Drupal node and object into Fedora 4. That means that we're moving RDF and everything to a Drupal node. Internally, LDP does not working that way. maybe, to be able to mimic it better, we could rethink that and make different entities for different parts of an object. Versioning using the node as the object can get complicated - versioning on different parts would be better.

  • Entities has been brought up quite a few times (OR2015, Islandoracon). Nothing wrong with doing it that way, and this is a good time to discuss it. Danny learned a lot of Drupal in the process of building CLAW, and the choice to make everything nodes was not necessarily an informed one. It's probably better to have things defined in a more granular fashion because of versioning. Lining up versions in Fedora with versions in Drupal would be just the best.

  • Kevin: Suggests modelling things in Drupal as closely as possible to how it's modelled in Fedora. I.e, if there is an Author field, map it to an Author object in Fedora.

  • Diego: Drupal Field Query module can mitigate the issues.

  • Lingling: ++ for Diego's idea. Was surprised when delving into code to discover it was all on the node. Entities will allow more flexibility in the future.

  • Diego is doing work on this and building a diagram. Does not want to start major work until he gets thumbs up on the diagram.

  1. Tickets

  • Thumbnails is a bigger question than we thought. Where should derivatives live? Fedora? Drupal? If we have an upgration, they are now in Fedora, so where do they go? Underlying question of "who is the Master?" We take Fedora out of the pageload, but where does it belong? How do we give the user control over configuring this? This is a discussion from way back in the project, and the desire to take derivatives out of the preservation layer for faster display and scalability. But then they must be kept synced up. Nick and Dany took the approach that only archival assets belong in Fedora - but that's not a great fit for migrations, which will be a large part of the use cases. The archival copy can regenerate everything else. For Basic Image this is pretty simple, but for bigger files such as Video the question gets more complicated. By having camel and karaf in place the derivatives will not be generated on the web server, which makes large files much less of a hit. Maybe the line between derivatives stored in Drupal versus Fedora is how hard is how long it took to generate them (i.e, a thumbnail is quick and easy in Drupal. A mobile-friendly video, not so much)

    • Opinions are mixed - but there is support for not storing derivatives from both greenfield and migration folks. Best option is to write it as an option so that users can decide which works best for their case.

    • If we store all in Fedora, it would make upgration from 3 to 4 much smoother. Each individual resource can trigger its own action instead of having a top level resource. Our Drupal object would be a little more verbose, but that's not necessarily a bad thing. If we don't use the Drupal image processing, we just need ot make it clear to the user that we're not. This would also make it easier to re-implement in another CMS. Using different fields for different displays is pretty simple.

    • We are at time, so the rest of the agenda is table for the next call.

You may be looking for the islandora-community wiki · new to islandora? · community calendar · interest groups · roadmap

This is an archive. For new Tech Call notes, click here

⚠️ ARCHIVED Islandora Tech Calls

⚠️ ARCHIVED Islandora User Calls

Clone this wiki locally