Page History

...

1. Initial Performance Testing from Chris.
   • 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. (REST) Scripts & Processes endpoint: https://github.com/DSpace/Rest7Contract/pull/17
4. 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.

5. Not discussed much, but could there be opportunities to use Travis CI + Docker Compose for testing of Angular??

   • Docs: https://docs.travis-ci.com/user/docker/#using-docker-compose
   • Blogpost on how to do it: http://elliot.land/post/using-docker-compose-on-travis-ci
   • An example travis.yml file: https://github.com/Ortus-Solutions/docker-buildfiles/blob/master/.travis.example.yml

Notes

• Authorization display in UI: How to pass Authorization rights (i.e. logged in user's access rights) from REST API to Angular?  See for example: https://github.com/DSpace/dspace-angular/issues/393
  • After much discussion, we've realized there may not be a single solution to this problem.  Though more analysis is necessary to determine that.
  • Tim has started a Managing Authorization info in Angular UI wiki page for early ideas/brainstorms.  The initial ideas brought up in this discussion are noted there already
• Scripts & Processes Endpoint: https://github.com/DSpace/Rest7Contract/pull/17
  • Tim still worried about scope creep here.  Asked for more info on the proposed backend solution
  • Main questions are around the proposed "/api/system/processes" endpoint in the REST Contract, as it seems to require several features that don't currently exist on the DSpace backend (Java API or database or Solr).  Some of those seemingly non-existent features include:
    • A way of tracking currently running DSpace processes, their start-time, current status, runtime parameters, etc.
    • A way to assign UUIDs to all processes, and link those processes to DSpace user accounts (UUIDs)
    • A way to see the output of finished processes individually (currently most processes just log to the DSpace log file, not to individual log files)
• I18n status update on https://github.com/DSpace/dspace-angular/pull/366
  • Art noted that after further analysis, it looks like the "ngx-translate" PO file loader (https://github.com/biesbjerg/ngx-translate-po-http-loader) seems unmaintained, and doesn't seem to have many users.  It also seems to not be fully compatible with later versions of Angular, and doesn't work with Universal (SEO) yet.
    • This makes our ability to support PO files more complex...we'd have to fix this loader to work properly & with Universal.
  • The Angular project itself has taken a different direction altogether.  It uses XLIFF (instead of PO).  However, instead of managing translations on the client side, they are doing so on the server-side.  So, if you want an application to support 5 different languages, you'd build/deploy the application 5 times (one for each language).  If users want to switch language, they are actually switching apps (though their session info can be passed between apps).
    • Angular project claims this server side setup is much more performant for larger applications.  Unclear if we'll see this sort of performance problem though.
  • Neither of these solutions sounds ideal at this point.  We'd like to support common translation formats (e.g. PO or XLIFF) to make translations easier on translators.  But, there's not a clear "winner" between these options.
  • For the time being, we will stick with JSON (default format of "ngx-translate"), but flatten our JSON keys (to make things easier for translators)
    • We will track the PO loader for ngx-translate. If it gets more movement/support, we'll move to using it.
    • We will also track performance of ngx-translate. If we find that it's not performing well, we may eventually need to move to the Angular project approach (server side)