Versions Compared

Old Version 11

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version Current

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Initial Performance Testing from Chris.
    1. https://cwilper.github.io/dspace-perftest/
  2. (REST Contract) Edit Homepage News: https://github.com/DSpace/Rest7Contract/pull/45
    1. Delayed until after Preview release. General agreement (in meeting on March 21, 2019) that storing HTML in metadata fields is not really ideal behavior.  Metadata (from a librarian standpoint) tends to be free of format-related markup (as that allows for easier sharing, understanding of metadata.  Currently Community & Collection homepage information is HTML-based and is stored in metadata that is appropriate for a minor subset of information (like the title) but it is better to move large/rich text to bitstreams.  
    2. Proposal here is to consider storing HTML-based markup (for Site, Community & Collection homepages) in Bitstream(s) associated with the object in question.  May allow for more CMS-lite behavior in the future
    3. Timeline for this is uncertain.  Possibly in 7 or 8. May depend on how/whether it can be scoped.
  3. Concurrency in DSpace 7 (or 8).  What do we want to do when multiple editors are editing the same object?  Needs further analysis regarding implementation details
    1. We've decided (in meeting on March 7, 2019) to use ETags to implement concurrency. REST Contract notes on ETags: https://github.com/DSpace/Rest7Contract#etags--conditional-headers
    2. ETags only update of the two fields match. If someone edits first, your edit would fail and you would get a fail response (422?)
    3. ETags seems to have broader support in other REST APIs.  Recommended also by both Art and Andrea.

Notes

  • Discussions of Managing Authorization Info sharing between REST API and Angular UI
    • Andrea talked us through REST Authorization notes
    • Also contract on "resourcepolicies": https://github.com/DSpace/Rest7Contract/pull/87
    • All agree this "features" endpoint seems in line with ideas from last week's discussion
    • We need to keep a tight scope here...we don't want to reinvent/recreate the Authorization system in v7 (that's out of scope).  But, we do want to see if we can remove authorization "decisions" (i.e. code) from the Angular UI layer, and ensure they are made in the REST or Java API.  In v6, some of these decisions were in the Java API, but some were wrongly made in the XMLUI and JSPUI.
    • Ben questions on how to get embargo dates back from new "features" endpoint? Andrea notes that the embargo date will be available from the resourcepolicies endpoint (at least for now).  So, this may need to be two calls.
      • Tim notes that in future (v8 or beyond) there may be opportunities to simplify (and maybe even remove need for resourcepolicies endpoint), but we need to not put too much in scope of v7.
    • TODO: Andrea will create a Contract for the "features" endpoint for next week
    • Implementations for both these endpoints (resourcepolicies and features) is being planned for new student working at 4Science
      • These are HIGH PRIORITY endpoints though, so the sooner we can agree on REST Contracts, the sooner the implementation can occur & get reviewed.  Maybe even by end of Nov if we act quick.
      • TODO: All should review resourcepolicies contract to move forward.  Also review the notes Andrea created on (upcoming) features endpoint to ensure no further major questions.