Time/Place

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

Attendees 

Agenda

  1. "Prefer: return=minimal", should it Hash and Skolem resources be include... that have not in the past
  2. Fedora Specification updates
    1. Messaging SPI
    2. Atomic Batch Operations - name? BatchOps?
    3. CRUD
    4. Resource Versioning
    5. Binary Fixity Checking
    6. Authorization
  3. Recent test results
    1. Unknown User (bbpennel): PCDM
    2. Esmé Cowles: MySQL vs. LevelDB
  4. ...
  5. 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. Blank nodes and hash URIs created on a resource are not currently returned in a minimal representation. It doesn't seem an actual decision was made for this behaviour, rather it just became the default. Should we alter the current behaviour that says if you have recorded these hash URIs, then you should return them as part of a minimal request. A. Soroka, Unknown User (acoburn) & Esmé Cowles all feel that this should be done. No one spoke in opposition to this. A. Soroka will create a ticket around this. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  2. Specifications
    1. Atomic Operations just put to In Review, please review and comment.
    2. Versioning one has had some work, please review as well
    3. All the specifications should be reviewed and commented on as one would like.
  3. Recent test results -
    1. Unknown User (bbpennel) -  PCDM testing, any gaps people would like filled in. In this testing. Seemed like there is alot of indirection going on, wondering why people were avoiding the natural Fedora hierarchy.

      Esmé Cowles : Good for helping guide implementations.

      Diego Pino Navarro : CLAW is depending on Direct and Indirect Containers in the services only.

      Unknown User (bbpennel) : Are you using them (direct or indirect containers) for how you are modelling the data in Fedora?

      A. Soroka : Islandora CLAW is hiding the implementation details from the clients. Hydra users seem to be more aware of the actual data format in Fedora, whereas Islandora users are more separated from Fedora.

      Jared Whiklo : CLAW is brand new so it is sticking closer to the PCDM spec.

      Unknown User (bbpennel) : Are you using the stuff from the PCDM flat storage design and are you exposing the triplestore?

      Diego Pino Navarro : In CLAW we are using the flat storage, and we are exposing the triplestore sort of. We have both Fedora and Drupal triples in our triplestore. We would want people linking to get back to the Drupal URI.

      Esmé Cowles : Trying to figure out if stable path URIs are important to alot of users. If you have URIs that depend on collection membership then changing the location can make it more difficult. Possible, but more difficult. Expectation in Hydra is you are just removing one base URI and replacing it with another so your front-end to back-end mapping is stable.

      Unknown User (bbpennel) : There are some performance differences in the testing but nothing huge.

    2. Esmé Cowles : MySQL, PostgreSQL, and LevelDB Performance
      Now you can have PostgreSQL & MySQL as well as LevelDB. PostgreSQL seem to perform a little better than MySQL but both are a little slower than LevelDB. In the critical path the performance is all about the same. So we want people to migrate soon or stay where they are and push when Modeshape 5 comes out. Providing this functionality for people who want it is good, but people will have to upgrade when ModeShape 5 comes out. So we don't want to force two upgrades.

      Doron Shalvi : Interested in clustering doing some already in a "roll your own" context. Haven't migrated to Fedora 4, done some testing and ran into some memory issues. Need to revisit those issues. What we've heard regarding the shift to alternative DBs. Probably like to wait for that to stabilize before choosing. If they had to move to Fedora 4 right now and it doesn't support clustering, then they would develop their own solution, but would prefer a Fedora "supported" solution. No opinion for PostgreSQL vs MySQL, slight preference to MySQL as they already use that. Haven't spent a lot of time on this issue.

      Esmé Cowles : With Infinispan there is an option to put the binaries in the database, but also not sure what ModeShape 5 will do to that.

      Doron Shalvi : If both dbs are performant then no preference

      A. Soroka : We were interested in squeezing any performance enhancements out and went to LevelDB without inklings of stability issues. Now there are other concerns and other options to solve those issues.

      Doron Shalvi : So we would prefer stability over performance.
  4. Inflight tickets
    1. Esmé Cowles : FCREPO-1837 - unbalanced brackets issue. Needs a rebase. We should remove brackets or do some input validation.
    2. Jared Whiklo : FCREPO-1832 - Should be FedoraResources instead of JCRTools, should be secured where ever it is. Can't be deleted or modified. If you don't have AUTH enabled then you can't expect any protection.

 

4 Comments

  1. In messaging SPI:

    A batch operation that fails or is rolled back MUST NOT emit any messages.

    A single failed operation (HTTP 4xx or 5xx) MUST NOT emit any messages.

    Events MUST NOT be emitted until after any changes have been persisted to durable storage.

    The third condition seems to entail the first and second one, should it be moved up before the other two?

    1. No, I think the 3rd condition would entail the others if it were changed to "Events MUST NOT be emitted unless any changes have been persisted to durable storage." As it stands, it is discussing ordering, not existence.

      1. Makes sense. Thanks for the clarification.

        1. Well, it's just my interpretation: maybe the meaning is entirely different! (smile)