Versions Compared

Old Version 5

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version Current

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • (50mins) Discussed updated proposal for Angular : library-based architecture proposal  (the new updates are in the section titled "POC Analysis Overview" midway down that page)
    • A new proof of concept branch has been created by 4Science at https://github.com/4Science/dspace-angular/tree/f/ej/nx-poc
    • Discussion of benefits of the Standalone components and NX itself.  See wiki page for that list.
    • Feedback:
      • General interest from others
      • Need to analyze the risks (short term and long term) of these approaches.  A lot of benefits are listed, but it's unclear if there are any risks.
        • This may have more to do with library-based approach / NX. 
        • The "Standalone Components" idea is now the "best practice" way of doing things in Angular: https://angular.io/guide/standalone-components (There's a video on this page which describes benefits).  It can be used regardless of whether we switch to NX or not.
    • Next Steps:
      • All Developers are encouraged to try out the 4Science branch at https://github.com/4Science/dspace-angular/tree/f/ej/nx-poc.  Feedback can be added to the wiki page at Angular : library-based architecture proposal
      • Tim recommends 4Science may want to create an initial PR which is just  the migration to "Standalone Components".  This might be a good first step, as it doesn't require NX and seems like a possible "quick win".
      • We will revisit this topic in future meetings.  Because of upcoming vacations from key team members, it may not receive detailed discussion until later this Summer.  However, Tim will keep this on the agenda in case questions/comments come up in the next few weeks.
  • (10mins) Very brief overview of DSpace Preservation-enabled Storage via OCFL
    • Tim noted this came from recommendations from new Lyrasis CEO.  Project would be funded by / built by Lyrasis, but collaborations would be welcome.
    • General goal is to find a way to implement "object-based" storage in DSpace.  Tim tried to brainstorm a way to do with with the least amount of impact on how DSpace currently works.  Approach detailed in the document is just to replace the "assetstore" (which just stores bitstreams) with an object-based storage (which stores bitstreams and exported metadata).  Currently the recommendation is to look at OCFL, since that aligns well with this object-based storage approach.  But, other ideas are also welcome.
    • Initial document is really a rough brainstorm.  No prototyping or proof of concepts have been built yet.  No work has been done on this at all. We are just in a feedback gathering state.
    • Feedback can be added directly into that Google Doc.  Feel free to add comments inline, or add feedback at the very bottom (in the section for feedback).  Anyone can add feedback and you can add it anonymously if you wish.
    • Quick feedback in meeting:
      • General support for the concept of object-based storage in DSpace.  Others have heard this same need.
      • Concerns expressed over how to make this work without performance issues.   For example, we would not want to write every metadata change to this "preservation-storage" immediately after the change occurred...that could result in a lot of file writing which could bog down the system. But, also don't want the preservation-storage to not be very outdated.  May require a proof of concept.
    • Next Steps:
      • Tim asks for additional feedback in google document (
      see link above