Page History

Background

...

Contro: the build process of DSpace is already more complicated than the average of opensource web project. At the end we build just a single web app forcing maven to make extra work to manage all our dependecies with the risk to introduce hard to reproduce bug relative to transactional dependencies. This consider is not really specific of this project and would apply also for other dspace maven modules but in such case the benefit of eventually exclude a such lightweight implementation that don't rely on off stream libraries seems to be minimal

Vote: 

• In meeting on July 13, 2023 several attendees (namely Tim Donohue & Art Lowel) favored this "separate maven module" approach as it aligns better with OAI-PMH and SWORD.  The primary concern is around whether we should have generic LDN Java implementation code embedded in our "server webapp".   
  • If this LDN implementation code is larger in scale (like the generic Java implementations of XOAI and SWORD protocol), then it'd make more sense to have a new "dspace-ldn" module (or similar) which contains that generic Java code separate from DSpace-specific implementation code.  However, it's likely that this approach would still require some DSpace-specific implementation code to be in the "server webapp".
  • That said, if we find that the LDN implementation code is small  in size, it would be reasonable to have it contained directly in the "server webapp" (as in option 1).  This would be similar to Signposting (in org.dspace.app.rest.signposting), which has a much smaller implementation and most of the code is DSpace-specific.

Where the full LDN json messages should be stored? we want to keep also a copy of the original JSON message.

...

Contro: it would be slower and slightly more costly than other approach

Vote: 4Science

• In the meeting on July 13, 2023, several attendees noted that either of the first two approaches seem reasonable.  It'd be fine to store these messages in files... or, since they are small in size, they could be stored in the database (option 2).  However, we recommend AGAINST storing in a dedicated Solr core (option 3).

2) in the database, the json file as a text column (the same used for the text_value in the metadatavalue)

...

Contro: Nothing, as the discovery.xml already include default filter for all the configuration to specify which resources should be included in the result

Vote: 4Science

• In the meeting on July 13, 2023, there were no objections to making this an IndexableObject.

2) with a dedicated API

Pro: Nothing identified yet

...

No alternative proposals yet.

• In the meeting on July 13, 2023, there were no objections to the below concept at a higher level.

Current proposals (4Science)

...