Child pages
  • Hydra Tech Call 2017-01-18

This wiki space is deprecated

This wiki space is now deprecated. The wiki for Samvera (formerly the Hydra Project) is now to be found here: Samvera

Skip to end of metadata
Go to start of metadata

Time: 9:00am PDT / Noon EDT

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

Moderator: Thomas Scherz

Notetaker: James R. Griffin III

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. CanCan and curation concerns (Joe Atzberger)
  3.  Discuss AIC API work (Adam Wead, Stefano Cossu)
  4. (STANDING) Update on Sufia/CurationConcerns Consolidation Plan (Michael J. Giarlo or Justin Coyne)
    1. Hyrax branching and the Sufia upgrade path (Michael J. Giarlo)
  5. (STANDING) Sufia 7.3 Blockers - University of Cincinnati local sprint.  Thomas Scherz 
  6. Question from Hydra Plugins WG (Andrew Myers)
    1. plugins are trying to alter flow around characterization and derivative generation
    2. is actor stack the right integration point?
    3. does sipity work flow engine come into play here?
  7. Moderator/notetaker for next time:
    1. Moderator: TBA
    2. Notetaker: TBA

 

Notes

CanCan and CurationConcerns

  • Joe Atzberger did not attend the call

 

AIC API Work

  • Wead:
    • As Cossu was not originally on the call, was uncertain as to what to state
  • Giarlo:
    • Suggested that Wead and Cossu place this on the agenda
    • AIC developed an API which plugs into the Sufia base for their repository
    • Has heard demands for HTTP API's from other members of the Project Hydra community for shared Gems
    • Invites interested community members to review and inspect this work
  • (Cossu joins the call)
  • Cossu:
    • Clarifies that there are no plans to gemify the solution developed by AIC
    • This was built around a customized system
    • The scope remains narrow due to time constraints
    • Would be eager to see a collaborative effort arise which leads to gemification
  • Wead:
    • Proposes a HAPI Gem for projecthydra-labs
    • Would this help any community members interested in a OAI-PMH harvester?
  • Binkley:
    • Currently the OAI-PMH harvester is often found within a separate app.
  • Giarlo:
    • Clarifies that CRUD operations are supported for the creation of assets and derivatives, as well as the updating of assets
    • May wouldn't be one-to-one for OAI-PMH functional requirements
  • Pendragon:
    • Enquires as to what this is used for at AIC
  • Cossu:
    • Other systems which don't depend upon Fedora 4 for storage can leverage CurationConcerns
    • Further, provides custom derivative generation (provided by users or an external system)
  • Pendragon:
    • How is this API different from transmitting HTTP requests to CurationConcerns endpoints?
  • Cossu:
    • The multiple step process of file ingestion in Sufia required such development
  • Wead:
    • Essentially this work wraps the Actor around an API call
    • A POST request with a payload of some metadata and files is received, the validity is checked, and it is passed on to the Actor

Sufia/CurationConcerns Consolidation Plan

  • Giarlo:
    • Looking to cut a release of Hyrax release soon (0.1.0)
    • This would create a new 0.1 stable branch
    • 0.1.x work would be the migration target for parties coming in from Sufia and CurationConcerns
    • As there is still more feature work in Hyrax for Hydra-in-a-Box, this approach doesn't block this from being merged to the master branch
  • Myers:
    • Any concern about trying to having a 0.x release as  migration target? Wouldn't this be subject to change?
  • Giarlo:
    • Doesn't see many changes coming to 0.1.x branch
    • It should only have fixes (no minor or major updates) 

Sufia 7.3 Blockers

Scherz:
  • Dev. environments have been established and University of Cincinnati (Scherz and Horton) are starting to grab available issues
  • They will focus on those solved by ScholarSphere first
  • Looking to identify any additional stakeholders interested in this sprint
  • They will keep the conversation going on Slack and in Pull Requests

Question from Hydra Plugins WG

Myers
Taking GeoConcerns as a first case (it is effectively a plugin)
Also, written to be the one and only plugin for a CurationConcerns App.
Discussion revolves around utilizing integration points in the Hyrax stack
Identifying why those integration points might not be sufficient
GeoConcerns deals with a special set of files
Characterization flow changes a bit depending upon the file uploaded
GeoConcerns clobbers some methods which prevent it from integrating from another plug-in
The WG found that the Actor stack seems to be the right integration point
Myers to attendees: Is this true?
Also is the workflow engine from Sipity an integration point?
Scherz
Actor stack feels like the right point
Pendragon
No great answers...Actor stack is just a list of classes run in order
List is defined on the first Actor in the stack
Big issue with derivatives...property of the FileSet determines which derivatives to generate
Myers:
Is the decision to have only one FileSet an open design question for Hyrax?
Subclassing FileSets would require quite some bit of code
This dovetails a bit with the Hydra FileSets WG
In that developers should try to emphasize the need to generate derivatives from Files rather than FileSets
Has found that Actors stack Jobs...it's somewhat hierarchical
Is there some way to flatten this?
Otherwise these are nested Jobs within Jobs
Perhaps a queue-like structure?
Pendragon:
This is a hierarchy because jobs have dependencies
Myers:
Is there a way to resolve this dependency without introducing a tree-like structure?
Hyrax developers are lovers of Modules and mixing it in
Mixing these out of order brings in problems relating to method overriding and inheritance
They may try to code a mechanism for identifying intermodular dependencies
This could also be useful to implement for Jobs or Actors
Do any attendees have any knowledge of any Gems in the backlogs which enhance interoperability?
The next meeting for the Hydra Plugins WG is on 01/31/17

Moderator/notetaker for next time

1 Comment

  1. Heads-up to Joe AtzbergerAdam Wead, and Stefano Cossu that you're on the agenda tomorrow.