...

1. Please squash a bug!

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

2. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

3. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

Minutes

1. Using Java 8 streams for RdfStream interface

• Addressing the pull request (PR) as it stands...should we merge or replace it with something more ideal?
• No one is suggesting not merging the PR
• Does Coburn have time to finesse it?

• (Providing the background for the issue)
• Current implementation of fcrepo extensively uses Guava iterators
• Allows one to do lazy processing...functional idioms for writing codes
• Java 8 allows one to use core streams library, deprecating the need for Guava
• Best to use core packages rather than rely upon Guava

• Addressing the #getTriples function:
  • The function accepts an iterator (must, hence, be changed to a stream, as specified above)
  • However, accepted by the function are name of implemented Classes
  • These correspond to approximately 8 sets of triples which could be requested (e. g. membership, versioning, fixity...)
  • As a consequence, this introduces a hard dependency on ModeShape implementation of fcrepo
  • In turn, this precludes any further abstraction, inhibiting the implementation of non-ModeShape fcrepo
• Hence, this PR introduces an enum
• Covers all of the cases currently in case with the ModeShape implementation and prefer headers in REST API
• As an enum, it doesn't allow for any extension of these values
• An idea proposed by Soroka is, rather than using the enum, use an interface or set of interfaces which can be passed in

• Is there time to find a more ideal solution to enum now?
• Or, is it viable to avoid merging now (merging the PR without an alternative to the enum solution requires that work be thrown away later)

• The PR is quite large
• 1/10th of the entire code base; Rebasing it is complete hell
• To keep iterating on this in order to add additional functionality while merging other PR's into the code base presents other problems
• Specifically, the task of managing the PR becomes increasingly difficult
• Definitely should remove enum, but advocates merging the PR as it is
• Then, replace enum immediately after

• He wouldn't have the time to refactor the PR with the preferred solution

• We all agree that this must be redesigned
• Not suggesting that this is a blocker
• Not volunteering to refactor the enum

• In thoroughly addressing the ticket...it became apparent that all of the implementing classes in ModeShape impl. would need to be rewritten
• Ideally, these would be separate pull requests, but they aren't

• Two different things bundles into a single PR for this ticket
  • Migrating way from homegrown iterator (addressed using Java 8 core)
  • Mechanism for identifying the triples desired for underlying repository
• First goal is accomplished

• Preferred that this not be released with the enum
• But, it is harder to merge later on, and best to get everyone on the same base

• enum Might still be a blocker for the next release

• Agrees, merge and consider the enum issue to be a blocker

• Consistent amount of changes into the code base
• Concerted effort to avoid introducing breaking changes for HTTP API (and other API) levels
• Aiming for a 4.5.1 release
• Could be value in this...relates to third agenda item
• Removing an endpoint (deprecation, breaking change)
• Good to get a "point" release out which alerts the community to this

• Should enum remain a blocker for a point release?
• Less than a month required for addressing the enum question?

• This is not a part of the public API
• Hence, can wait to resolve enum issue until this affects a component of the public API
• No need to block a "point" release
• Just desires to set a time limit to rectify this problem

• People will want to implement the API
• This will still block these efforts

• Will write the ticket
• Refactor the enum approach
• Make it a high priority, try to address this immediately and jointly
• Enable alternate implementations to then be written

2. Package Naming and organization

• Somewhat related to agenda item #1
• Number of new classes and interfaces in kernel API (4)
• 3 are in the base level org.frepo.kernel.api
• 1 is an implementation api.rdf
• Uncertain of a good location for these...do some constitute an implementation?
• What are these packages inside and outside of the kernel API?
• Generally speaking, all of the code within a given package may be referenced
• But, try to avoid loops
• e. g. The api.exception package references api package, which internally, then references the api.exception package
• Usually not the best practice
• Raises the larger question of...what are these packages?
• RDF package has one class within it
• More inclined to have have fewer packages
• Other approaches prefer more specific package names
• Circular dependencies are also really bad in ModeShape

• ModeShape is a monolith
• Discussions have been had regarding similar

3. Removing the FCR nodetypes

• fcr:nodetypes endpoints permits LDP client to find all of the resources within Fedora
• The link describes all of the RDF classes, includes all of the JCR hierarchies
• Most of the time, repository resources shouldn't need to know anything about the JCR hierarchies
• No strong argument to retain this endpoint

• Few likely know about this endpoint, fewer probably use it
• Yet, this would still constitute a breaking change
• Should alert community
• Add a warning header to this endpoint indicating that this is to be removed
• Perhaps adopt a policy to ensure that these deprecation warnings are issued
• Further, specify a term of time

• Best to have deprecation
• Ideally, header should have the time frame
• Not just a generic warning, but specify a date for the removal

• E-mailed the list 2 weeks ago
• https://groups.google.com/forum/#!msg/fedora-tech/1Gfsln0Ugug/lcoIP3DBCQAJ
• 4.5.1 deprecation release should issue the warning
• 4.6.0 deprecation release should no longer feature the endpoint
• Note that this information is not in the header for the current PR

• Most won't see the deprecation release until there is a "point" release and they upgrade
• Suggests that there should be a deprecation warning, released in a "point" release
• Then, others have the opportunity to take some action, introducing the breaking change in the succeeding "point release"

• Perhaps distinguish between core features people are using and those not likely being used by many
• For features being actively changed, 6 - 12 months

• Several months might be a good guideline
• But, far less time might be fine for core features which aren't used
• Key is to effectively use version numbers

• Major releases should be well organized and with the proper notes

• Before making a breaking change, identify deprecation within a header message
• Ideally, target release where the deprecation
• There will be cases where this might not be possible (sticks around for a number of releases)

• Good practice to specify that this is removed in 4.6.0...being that specific would be the most helpful
• Avoid specifying a date and missing this deadline makes it less predictable

• The ticket for this already exists, any should be in the position to add a PR
• https://jira.duraspace.org/browse/FCREPO-1892

4. Moving from LevelDB (ModeShape-specific storage for objects)

• By default, use LevelDB
• Can now use MySQL in code base
• Esme's PR offers integration for PostgreSQL

• Corruption issues for LevelDB have been identified in at least one e-mail thread
• Bulk ingest with an "out of memory error"
• Tomcat hangs, must be restarted

• Scripts from Muhammad from U. Maryland
• Works for some in identifying corruption in the LevelDB

• Part of the ModeShape move away from Infinispan seems to be to move towards a RDBMS
• Try to align ourselves now by preparing to move towards an approach which leverages these

• When ModeShape 5 is released, JDBC supports PostgreSQL
• Migration would still be required

• What is required in moving from LevelDB to MySQL or PostgreSQL
• Fedora 4 offers a backup & restore/JCR export feature
  • Not ideal, won't show up in Fedora specification, but still there
• Yinlin successfully tested a LevelDB to MySQL migration

• Esme started performance testing (against LevelDB and MySQL)
• Might we change or suggest that LevelDB be avoided?

• How hard to push on JDBC backing for Fedora 4?
• Should we wait until the ModeShape 5 release?

• Not a long time to wait...confusing to offer this support
• Then, introduce the new migration

• Advocates using a "point" release in which MySQL and PostgreSQL (or both) are supported
• ModeShape 5 would then trigger a major release for Fedora

5. Fedora Specification Updates

• 6 documents
• Sections of Fedora specification
• All being drafted (and in various states)
• Call from involved persons to produce a summary

Messaging API

• Finished drafting
• Invites comments

Atomic Batch Operations

• https://docs.google.com/document/d/1Ij4lFomcOJuOiWptZPyhP_wBRtxbqBP3_Rdw1eKmClM/edit
• As this was essentially an initial attempt, would appreciate someone to hack it apart
• Still would prefer to iterate and refine the document

Authorization

• Want to watch how others are starting the process
• Intend to have something substantial for the next meeting

Bahulekar:

• WebACL spec. leaves some room for interpretation
• Best to tighten up the ambiguities which are there

CRUD

• Complete from the perspective of the immediate adjustments to LDP
• Open question about how to handle PUT creation
• There was pretty heavy discussion on this

• Following the conclusion to this discussion, these points must be addressed
  • Any possible content restrictions
  • Which triples are allowed
  • Any formal specification of the prefer headers (or other fcrepo specific headers)
• None of these are featured

• So far, writing into 2 sections
• First section addressed specifications in LDP which need to be refined

• Second section addressed unspecified in the LDP which need to be specified outright

• Invite feedback in order to gauge the navigability of the document
• Use sections to align with the LDP spec. section numbers
• Need to resolve comments on the document before this can be addressed