Not directly applicable to DSpace 7, but may be of interest to folks here. They are starting to discuss changes to DSpace data model (likely arriving in DSpace 8, at earliest).
Join the #entities-wg Slack channel and future meetings for more info. All meetings also recorded.
In Angular 5, Rxjs has had an update. We'll need to refactor our code based on this (may be more little-by-little, rather than all at once). Not a rush as the old way of chaining Rxjs operators is still supported (but may be removed by Angular 6). https://github.com/DSpace/dspace-angular/issues/201
ACTION: Art to add more examples to ticket of what to look out for, and how to correct this in code.
Lotte is working on search page truncation. PR should be coming soon.
Question (Pascal): Considering the frequency of Angular updates, after DSpace 7 are we still planning to stick with our yearly release cycle (for major releases)?
YES, we have no plans to change DSpace's release cycle. This may however mean that major releases of DSpace occasionally jump over an Angular release. (e.g. maybe DSpace 7 will use Angular 6, while DSpace 8 may use Angular 8).
Art notes that Angular has a formalized release cycle now as well. They do a major release every 6 months
Andrea notes that Angular update frequency will also affect institutions who have locally customized DSpace, or have custom plugins that modify the Angular UI. We have to communicate this well, and keep them in mind too.
Art also notes that Angular provides great online tools for how to upgrade your local code between Angular releases. You can select what version you are on, and select what version you want to upgrade too, and they provide a checklist of all the changes you'll need to make to your local code. We could share this as part of our DSpace Upgrade process in future.
In the future, we may want to ensure the "master" branch is always running the latest version of Angular. But, we still won't cut a new major release more frequently.
Giuseppe notes he's hitting a few issues:
POST / PATCH requests aren't working correctly. The first request seems to be cached, but after that the caching is not seemingly working right
However, Giuseppe notes he's running latest and still seeing this odd behavior
ACTION: Giuseppe will create a ticket for this, and link Art to his branch and/or sample code. That way we can see if Art can reproduce and find a solution.
Also issues with working with WorkSpace Items in Angular UI. The DSpaceObject parser isn't working properly for this purpose?
Art notes we may need to change the code here to deal with them. But, likely needs more info from code to give more advice
ACTION: Giuseppe will create a ticket for this, and link Art to his branch and/or sample code.
Side discussion on Slack notifications
Are the Waffle board notifications for Angular tickets (in #angular-ui) useful?
Yes. let's leave them. Good to see activity as it is happening
Is there something we could similarly use for JIRA for the #rest-api channel?
Not sure.
Patrick noted a few possible plugins to investigate
Tim notes this looks fine. However, we should log that there's a bug in the SolrLoggerUsageEventListener as a ticket. We don't want this commented out for DSpace 7, as it essentially turns off usage statistics for this REST API
ACTION: Terry will log. (Update: already done: )
Question (Tom): Are we still "supporting" the Legacy REST API in DSpace 7?
YES. It will be released as part of DSpace 7, but will be deprecated. It will then be removed in DSpace 8. This gives institutions time to migrate their tools/integrations to the new REST API.
Note however that the Angular UI will NOT work with the legacy REST API. So, everyone will be required to run the new REST API for Angular UI. They can just optionally choose to also install the deprecated, legacy REST API alongside that.
Are we still planning to version the REST API?
Yes, we should version the new API. It can be versioned separate from DSpace itself.
4Science is currently working on MyDSpace (User Profile).
As discussed previously, MyDSpace should now be updated to use Solr / Discovery to locate Workspace Items and Workflow Items
This will require a new Solr Core, specific to searching Workspace/Workflow items. It will also require modifications to the Discovery REST endpoint
Why do we need a new core? Could we just use the main search core?
The main search Solr core (for Discovery) is very actively searched, as it is used on many public pages. It is not updated frequently, but has high activity
For Workspace/Workflow items, the core will need to be updated frequently, but the number of items will be small (at any given time). Because of the frequent updates, this could affect public browsing/searching if we were to do this in the main search core.
All agree this seems like a good approach
4Science will be providing more info / documentation on this in progress effort in coming week(s)