Page History

...

1. Last-Modified date design

   1. Andrew: Last-Modified wasn't changing when IndirectContainers were creating new child links

   2. Esme: Also updating when inbound links were created (because we were creating reciprocal links)
      1. Action: Esme: add to the design page
      2. Experimenting with explicitly managing our own last-modified property, or not creating reciprocal links
   3. Jared: Would that work include the various last-modified properties in the design page?
   4. Esme: No, that would be another ticket and could be more involved.
      1. I'll push my branch up and update the relevant ticket so people could find the work if they had time to look at this

2. Hash fragments: review description

   1. Andrew: We should more description of the intended behavior to drive the implementation discussion

   2. Aaron: Are we talking about a specification like a TCK would involve?
      1. Hash fragments are not repository resources
         1. They can have properties, updated with standard CRUD operations (POST, PUT, and PATCH)
         2. Their properties would be included with their parent resource's properties
         3. Any repository resource can link to hash fragments without restriction, or management by the repository (e.g. their base URI wouldn't necessarily be adjusted if the repository base URI was changed).
   3. Adam: hash fragments can be created anywhere using the standard CRUD operations
   4. Esme: there are some permutations of hash fragments as objects:
      1. existing in the base resource
      2. pointing to another repository resource that exists
      3. pointing to a repository resource that doesn't exist
   5. Esme: there is some tension between referential integrity enforcement (which we want in many cases), against supporting full-featured linking like we expect on the open web
   6. Aaron: some of the use cases might have contradictory demands
   7. Andrew: we should be aware of this possibility and try to prioritize use cases.
   8. Andrew: reviewing design document:
      1. Current implementation (JCR nodes)
         1. Item 2: we don't want referential integrity enforcement
         2. Item 4: we don't want to have to delete the base resource to delete a hash fragment – they should not exist if there are no triples that mention them
            1. Adam: we should follow HTTP guidance: the hash fragments are not resources, and we should remove them if they don't have properties
         3. Item 5: hash fragments should be able to have "/" in the fragment identifier

3. Tickets to be removed?

   1. Please review these tickets (esp. if you are the reporter) and justify them if they should be kept, or close them as Won't Fix.
4. Investigating alternative ISPN backends
   1. Andrew: We should investigate using other Infinispan backends (e.g. JDBC database backend).
      1. The LevelDB wikipedia page notes it's prone to corruption, and it lacks good backup tools.
      2. LevelDB seems to work just fine, but it's worth looking into alternatives
5. Code4Lib Philly post-conference event?
   1. Some people aren't going this year, may not have an event.
   2. Get in touch with Andrew if you're interested
6. Next release?
   1. It would be nice to have a release before the end of the year