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

• Chris walked us through early performance testing results at https://cwilper.github.io/dspace-perftest/
  • Test data set & more info is at: DSpace 7 Performance Testing
  • A few areas that need work were called out:
    • Top Communities list on homepage takes over 2 seconds, see this table: https://cwilper.github.io/dspace-perftest/report/2019-06-04/7.0-preview-1/details-big#big-a-home-requests
    • Browse By Title with lots of larger bitstreams takes forever (26+ seconds), see this table: https://cwilper.github.io/dspace-perftest/report/2019-06-04/7.0-preview-1/details-browse
  • Ideally, all REST queries should be <2 seconds (at slowest)
  • Andrea points out overlaps here with Projection discussions, see 

    Jira
    server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key DS-3533

    • Projections would let the UI limit what info is returned per request.  This could speed up individual queries significantly, as often the UI doesn't need all metadata or all bitstreams... but currently all queries return a lot of embedded content, etc.
    • Need to revisit Projections in light of these results
  • Lots of suggestions for future performance testing areas (to enhance future data sets, testing points)
    • Testing performance from an SEO perspective (tests that act as a web crawler)
    • Testing performance of Entities (e.g. an article with many authors, or an person with many articles).  Paulo mentioned he has some real life data that could be used here
  • Additional suggestions should be added to Wiki page at DSpace 7 Performance Testing
• Laura briefly overviewed her design proposal for Community pages:
  •  See: Community page mockups
  • Designs were based on local user feedback at NYU
  • Discussion here was limited (as first topic ran long).  However, all are encouraged to bring these designs back to your institution for feedback/analysis.  Also looking for additional "Design objectives" (based on other local user testing).
  • REVISIT in meeting on August 1 (in two weeks, because Laura is out next week).  This topic will be first on the agenda that week.