Page History

...

• Improving performance / scalability in general
  •  e.g. high High CPU usage for server-side rendering, https://github.com/DSpace/dspace-angular/issues/3110
  • Serve configuration more efficiently: https://github.com/DSpace/DSpace/issues/9056
• Configurable Entities (by default)
  • What do we need to achieve to enable Entities by default?
  • How can entities be made more usable?
  • Improving scalability/performance/functionality of Relationships
  • Nested/hierarchical metadata  (e.g. dates on a Person's affiliation with an OrgUnit)
• Angular : library-based architecture proposal - As of 8.0, we've already migrated to "standalone components". We can now consider whether to potentially migrate to using Nx.
• Shall we automatically change metadata in flyway migrations? 
  • Entities
    • If entities are enabled by default how could a migration look like? Shall we offer a script to add a field dspace.entity.type="Publication" to all items without an entity type? 
  •  DOIs
    • Changing the field a DOI is using (dc.identifier.uri vs. dc.identifier.doi)
    • Changing the resolver (https://doi.org vs. http://dx.doi.org)
• Bitstream persistence

  • Current behavior

    • Current URLs on item pages are similar to /bitstreams/2d35dc29-47a7-4a62-a87b-8b1fb10594ee/download

      • This will first handle authentication, and hereafter redirect the user to the REST url

    • The REST url is similar to /server/api/core/bitstreams/2d35dc29-47a7-4a62-a87b-8b1fb10594ee/content

      • This can’t handle authentication, and is used by Google (the URL which is indexed) and most often by users if they want to share the link to the file

    • If you need to replace the bitstream, a new bitstream has to be created with a new UUID, and the old bitstream has to be deleted. They are in no way linked to each other

    • When using versioning, and not changing the bitstream, the new item will contain a bitstream with a different UUID, which references the same file. They are not related to each other in the bitstream’s metadata. Cut there are two URLs which both point to the same file. This may lead to perceived duplication of the files as well

  • Desired behavior

    • The urls should both be independent from the UUID if we want to allow url persistence

    • The newly uploaded bitstream should be linkable to a bitstream it’s replacing. And the bitstream of the new version of the item (during item versioning) should be linked to the bitstream from the older item

    • In DSpace 6, this was handled using the sequence ID. Download urls were based on the combination of the item’s handle and the bitstream’s sequence ID. This concept could be used to support replacing a file while keeping the URL consistent

    • In DSpace 7, there’s also versioning support for items. Depending on the configuration, the handle without suffix would always lead to the latest version

    • Based on these concepts, it should be realistic to build a URL for both Angular and REST which can at all points in time link to the latest version of the file

• Replace Submission Form library (as the one we use is unmaintained): https://github.com/DSpace/dspace-angular/issues/2216
• Permissions
  • Possibility of granting granular permission to individuals and groups to edit / see only some metadata

...