Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

Date

Angular meeting

Attendees

Notes

  • Since the last meeting most of the setup tasks have been done
  • William added an Ahead of Time (AoT) build
    • it's a build process that is used in production and does things like compiling templates ahead of time, and remove unused dependency code, so the amount of javascript that the client needs to download to start working is much smaller.

    • But it takes a lot longer to build, that's why we still have a separate webpack build for development.

  • Giuseppe & Matteo added a PR for unit tests
  • The first set of tasks for the browse workpackage has been added to the waffle board
    • focused on the models: to create them and to get them from the server
  • Art added mock REST endpoints 
    • Not complete or entirely accurate yet, just enough to do some tests on deserialization
    • This should be enhanced as REST API gets built/updated
  • Documentation enhancements. How to get started, etc
  • Redux / Ngrx
    • Compatibility with angular universal has been verified: it works fine.
    • Opening and closing the header menu has been rewritten using Redux. 
      • This has already been merged
      • An explanation of the parts can be found on the PR for now
      • There will be another update next week, afterwards the explanation will move to the wiki
    • There's a browser extension for chrome and firefox called Redux Devtools: 
      • https://github.com/zalmoxisus/redux-devtools-extension
      • It will show the entire history of the state of the application, what the initial state was, which actions were applied to it in which order, what their payloads were, what the diff was between the states and so on. 
  • Tests with JSData 
    • Not a great fit. Typescript support isn't great (beta). Support for JSON API spec also not perfect. 
    • Recommend AGAINST using it for now.
  • Waffle Board
    • Code Reviews / Testers would be helpful
  • Google Hangouts limits. Current hangout limited to 15. We had 13 attendees today.
    • Andrea B may have a system that has a 25 attendee limit that we can use.
  • Contributions call soon
    • Tim will set up DSpace Slack (next week, invites to all on this team first. Open up to all later on)
    • Tim will draft up call
  • William asks us to take a look at angular animations. It is getting to a point were we could consider using it.

 

REST meeting

Attendees

Notes:

 

Most of the discussion has been around the document available here. We ask all the interested developers to add their comments and thoughts: https://docs.google.com/document/d/1dAPjq6xSy7A5Q_xXIxLXgJ2VqugFpxeSmMmvbr2mM5M/edit?usp=sharing
  1. Dummy response for collection: https://github.com/DSpace/dspace-angular/blob/master/src/backend/collections.ts
    1. May not be an accurate representation of what REST API will look like
    2. REST Team should feel free to create tickets in Waffle (https://waffle.io/DSpace/dspace-angular)
  2. Question: If we want to mockup/describe an API first, we may hit issues with using Spring Data Rest or Katharsis, both of which structure endpoints in very specific ways.
    1. If we want to document our own API endpoints first and build an endpoint to meet that need, the only way to do that would be with something like Swagger
    2. Much more info here: https://docs.google.com/document/d/1dAPjq6xSy7A5Q_xXIxLXgJ2VqugFpxeSmMmvbr2mM5M/edit
    3. Comparisions of frameworks are all there.
    4. William: Pagination & partial data are needs
    5. Terrence W Brady: How is Solr involved in the REST API frameworks?
    6. Could use Solr as a data repository with Spring Data REST? (Spring Data has a connector for Solr, but could use Spring REST against Discovery?)
  3. Spring REST vs Spring Data REST?
  4. Spring Data might make our code more easy to understand (to Java developers)
  5. Our usage of Spring is complex (dspace-services). We need to consider removing this (we hide Spring context in our DSpace Kernel)
    1. William: Build process redone. Dependencies are complex and hard to update Spring
    2. Do we simply our application into one Webapp (REST, SWORD, OAI, commandline)? Currently running multiple JVMs
    3. Should we remove dspace-services (DSpace Kernel)? Yes, replace with Spring
    4. Should commandline turn into calls to REST API?
    5. Terrence W Brady: Long running tasks need a way to run in the "background"?
      1. Could these still be kicked off on a different JVM (or even different server)?
      2. Could we run two REST APIs? commandline could use a REST API which is only available from localhost (not the public one)
  6. Solr needs to be updated (to executable JAR version, Solr 5). Get rid of dspace-solr.
  7. ACTION: Start in a DSpace 7 branch in main DSpace/DSpace
  8. John Francis Mukulu: feedback on REST API: Pagination, translations, support for different datatypes, filters (level of detail) https://goo.gl/tPND8g
  9. API Versioning: brainstorm on how to deal with this sooner than later.
  10. ACTION: Andrea Bollini (4Science) will link John Francis Mukulu's brainstorm (Google Doc) and Terrence W Brady's (in GitHub) to the main REST API page. That way we have all this information in one place.
  • No labels