Hydra Tech Call 2017-04-26

Owned by Bill Branan
Jun 16, 2017
5 min read


Time: 9:00am PDT / Noon EDT

Call-In Info: 1-641-715-3660, access code 651025

Moderator: Esmé Cowles

Notetaker: Jennifer Lindner

Attendees:



Agenda

  1. Roll call by timezone per following order - ensure notetaker is present

    1. folks outside North and South America

    2. Eastern timezone

    3. Central timezone

    4. Mountain timezone

    5. Pacific timezone

    6. folks who were missed or who dialed in during roll call

  2. Hyrax 1.0.0.rc → release - justin
    1. Was scheduled for today. Postponed so that Anna Headley can test later this week.
    2. Tentatively scheduling for May 3rd
  3. Hydra Group Refactoring - Jeremy Friesen
    1. The issue that launched the analysis Hyku #421
    2. The issue related to roles Hyrax #250
    3. https://docs.google.com/spreadsheets/d/1r1R035qj13AFpZpgG9Nui1-JxvKJyQYrswH6RVbl1tM/edit#gid=0
      1. The columns are functional roles
      2. The rows are analogue to functional ability
    4. Proposal for CanCanCan Ability refactor
      1. This is a multi-step plan to begin to answer: Given a user, what abilities do they have?
      2. The current working branch that implements the first, and least invasive, of several steps
      3. We believe this is backwards compatible and could be pushed higher up into Hydra
  4. Hydra Documentation Working Group (bess)
    1. Call for Participation has ended (but if you missed the announcements and really, really, really want to help out, let us know).
    2. Participants: please fill out the Doodle poll for the Initial Meeting.
  5. External Files in Fedora (Chris Colvard (Deactivated))
    1. PR into ActiveFedora: https://github.com/projecthydra/active_fedora/pull/1234
    2. If PR gets merged, how can we take advantage of this further up the stack?
  6. Moderator/notetaker for next time (carried over from this cancellation):
    1. Moderator: Adam Wead
    2. Notetaker: bess

Notes


2. Hyrax 1.0.0.rc → release Was going to be released today but will be rescheduled next week, weds May 3rd, to give Anna Headley time to test.


3. Hydra Group Refactoring Jeremy Friesen)

Request to normalize group behavior, At Notre Dame we've been working on it for a month or so doing analysis, and came up with an approach plan, proposing a refactor for how we do cancan.  3c is link to a document with roles and abilities and what we're aiming for, we want our code to better produce those results.

3.d We have a working branch out there, with some of the code changes, will paste links into slack channel. The proposed code change is taking the god object and making submodules that can have roles and abilities - to map users and groups to roles and abilities. We're prepared to go forward with the branch but looking for feedback.

-- 10 minute timebox agreed to for this discussion --

Trey -- I don't see any Hydra API in the code.

Jeremy -- The ability class works, and next step is to implement APIS into the branch.

Trey -- Looking at what exists in branch now, I can see it's an intermediate step (complex but not much benefit yet), the most useful piece is the append abilities to.

Jeremy -- Yes, goal is when you load a user, what functional roles should they have, so if user isn't an admin you wouldn't call the admin stuff, and yes, append abilities is absolutely the most useful one.

Trey - it looks like abilities, logic for whether or not to apply a permission is attached to apply method of ability object -- are you heading away from that?

Jeremy -- Yes, eventually. The hydra groupie gem is where we think we want to end up. So, we want to make sure we don't have bugs here, and then, do you [people in the community] like this direction, should we be pursuing it? Should we do the hydra groupie gem? The basic idea is given a user, what abilities do they have, and that would make a lot less re-opening of the Ability class, which is a code smell.

Trey agrees about re-opening the Ability class.

LaRita - I'm interested in use cases, to make sure what we're doing is addressing them.

Question - where would you like the use cases?

Jeremy - for now, the guiding one [and place] has been on Hyrax 250, however, if you want to throw Hydra use cases on the Hydra Groupie gem that would work.

Question - what use case are you designing this based on?

Jeremy - Given who I am, what can I do, not given what I want to do, can I do it. And honestly to refactor the cancan object, because it's a tremendous barrier, and it moves up and down the stack too (Blacklight, etc). What we want is wherever an ability is, you can attach it. The db is a big change and not committed, but thought it was good way to articulate it.

4. Hydra Documentation Working Group (Bess Sadler)

The idea for this came out of LDCX, we had a call for participation on the Hydra-tech email list which ended yesterday, but if you're just hearing about it it's okay to get in touch, we're not turning people away. There's a doodle poll: https://beta.doodle.com/poll/uxkddrmia6r3332i#table for the time for our initial call. Our basic charter is to re-think how we do documentation, and you can see the beginning of it at http://projecthydra.github.io/.

Question – Is this only for developer documentation?

Bess – Our initial focus is, yes, but we've had interest from non-developer people, metadata people, and we hope the work will set an example and inspire other groups.

5. External Files in Fedora (Chris Colvard (Deactivated))

I was looking at how to store external streaming derivatives for Avalon. Esme pointed me to https://github.com/projecthydra/hydra-works/blob/master/lib/hydra/works/services/add_external_file_to_file_set.rb. Decided to push this approach into ActiveFedora to make it easier to use up the stack, and looking for feedback on the PR.

Adam -- Will it redirect you?

Chris -- Yes.

Drew -- The main motivation for original thing that got merged into hydra works, the practical goal, is for large works. There will have to be conventional way for Hyrax to deal with high latency. There was some discussion of that at LDCX of action cable... I like the direction, but my question is how do you deal with large files?

Chris - We want to track derivatives on streaming servers and metadata on the files, so large files are not really our use case.

Esme - At Princeton we keep all our files external.

Drew - There's implication that some fedora features might not work, is that correct?

Chris - Some things don't, like fixity checking - but it could.

Adam -- Do you think Fedora is responsible for fixity on external resources? (might be an issue if there's a separation between where files are and where that occurs)

Esme – It depends on your setup, and the Fedora tech call tomorrow might address this.

Drew -- Are you treating large files differently?

Esme – No, everything's on disk, served by web server.

Everyone should go to PR and comment there: https://github.com/projecthydra/active_fedora/pull/1234