Time/Place

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

Attendees 

Agenda

  1. 4.7.0 release update
    1. Related tickets:
      1. Memory constraint on /fcr:backup https://issues.jboss.org/browse/MODE-2587
      2. Duplicate ids from /fcr:backup https://issues.jboss.org/browse/MODE-2611
  2. 4.6.1 release - patch for concurrent resource creation
  3. Refactoring internal interfaces: IdentifierConverter and "getTriples"
  4. Code4Lib proposals
  5. Major remaining spec issues: Create-on-PUT, Headers vs. URIs for atomic ops
  6. ...

  7. Status of "in-flight" tickets

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Ticket Summaries

  1. Please squash a bug!

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  2. Tickets resolved this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  3. Tickets created this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Minutes

  1. 4.7.0 release update
    1. Andrew: Releases have been made, but not publicized yet.  But there may be issues with 4.7 when deleting PairTree nodes.
      1. Kevin: I don't think it's a problem with the deletes — I've been able to trigger the error with a GET
        1. May be specific to environment (Postgresql, Tomcat)
      2. Esme: I did my backup/restore testing with Postgres and Tomcat, and I can re-test and check if I see the same errors after the data is restored
    2. Memory issues with performing backups: see https://issues.jboss.org/browse/MODE-2587
      1. We have submitted a patch to Modeshape, they will do a release, and we can then make a new 4.6.1 release to use that
    3. Duplicate IDs: see https://issues.jboss.org/browse/MODE-2611
      1. We have submitted a patch to Modeshape, they will do a release, and we can then make a new 4.6.1 release to use that
    4. Concurrent creation issue/patch
      1. There is a patch to address this, included in the 4.7.0 release
      2. Will backport to include in 4.6.1 release along with items mentioned above
      3. Kevin: Have loaded data into a 4.7 repository, and haven't seen the issue that I was seeing before
  2. 4.6.1 patch release
    1. If the Modeshape backports are forthcoming, then we should wait for them
    2. Good to get this release out quickly so people can upgrade to it before migrating to 4.7, to avoid the backup/restore issues
    3. Should know very soon what Modeshape's plans are and be able to plan for coordinating the releases
  3. Refactoring internal interfaces: IdentifierConverter and "getTriples"
    1. Danny Bernstein is pushing forward from the work Ben Armintor did recently to address performance of resources with many links to other repository resources
    2. Internal refactoring would help make that work easier, so the performance work is waiting for the refactoring
    3. Converting identifier forms is complicated and messy in the current implementation, and there's some interest in replacing the existing Guava implementation with built-in Java 8 equivalents
      1. Bigger refactoring options include removing the getTriples function, or doing a conversion strictly from one identifier form to another (without loading JCR nodes, etc.)
      2. Doing identifier-to-identifier translation would then involve an extra step to load resources and their properties
        1. Esme: separating those two concerns sounds like a good idea to me, and could avoid performance side-effects of current process that loads resources whether you want them or not
      3. Loading resources and generating RDF are separate issues: you can load resources if you want (and identify them with an identifier), and the implementation can generate RDF as a stream, which may or may not require loading the resources your resource links to.  Doing the identifier-to-identifier translation makes this possible.
      4. Should we keep using Modeshape REFERENCE properties — or switch to using URIs or something else we could use to generate references without having to load the resource from the repository?
        1. We can currently get inbound references using those REFERENCE property links.  Do we lose that, or how do we reproduce it?
          1. We can reimplement it if we want, but some users don't want it or the costs
          2. Could index inside Modeshape and be able to get inbound references if we wanted to
    4. The consensus is that the identifier-to-identifier translation refactor is a good idea, and we can wait for more information before deciding on the other issues
  4. Code4Lib
    1. People planning to attend:
      1. Esme
      2. Nick
      3. Bethany
      4. Andrew
    2. Code4Lib proposals are due shortly
      1. Esmé: I've been talking with a few people about a data-modeling workshop, which would probably be of interest to people using Fedora
      2. Andrew: Maybe an import/export workshop would be a good idea?
  5. API Specification
    1. There has been a lot of work to move the API Spec forward, there are a couple of outstanding issues:
      1. CRUD: Do we need to specify creating resources with PUT? See https://github.com/fcrepo4-labs/derby/issues/11 and Fedora Specification
      2. Atomic Batch Operations: Headers vs. URIs
    2. Talk to A. Soroka if you have questions
  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.