assess sdr-client refactor to be more similar to our other client gems

[ndushay]

In doing research for the Folio Integration workcycle, I was chasing call stacks from the bottom up, and when I hit sdr-client I could't follow a large part of it.

The sdr-client gem, in a perfect world, could be refactored to be more like our other client gems (dor-services-client, preservation-client, folio-client ... whatever).

This ticket is to assess what it would take to do this refactoring and if we could do it in stages, or if it should be done all at once.

On consulting with @mjgiarlo, he said it would take approx 1 hour to do this assessment, and he would be delighted to do so after this week, when he is FR.

If it is just as much work to DO the refactor as to ASSESS the refactor, then ... please do it.

[justinlittman]

For what it is worth, sdr client is nothing like our other clients in that it is not simply a thin layer over the API. It includes much more logic to (1) fill in the request with defaults / construct the request from incomplete information and (2) handle the complexities of the ActiveStorage interaction. This is very confusing and it is quite possible that this code is over-generalized / over-abstracted, but I think the underlying task is not simple.

It would be helpful to know more about the goals / intent of this ticket.

[ndushay]

@justinlittman the intent is to make it understandable; I didn't understand the CLI stuff at all. Maybe that's a documentation problem. Maybe that's a "what are we doing with the sdr-api and why do we use it in some contexts and DSA in others" question, too. I think of myself as a reasonable "middle of the pack" canary with respect to "I can understand what this code is doing" ... and sdr-client made my head hurt.

from the README:

A primary design goal was for this to have as few dependencies as possible so that it can be easily distributed by gem install sdr-client and then it can be used as a CLI.

... where is it used for this? And should we keep supporting this?

[mjgiarlo]

I wonder if this should be an issue or a dev planning topic or a story time or ... ?

[mjgiarlo]

@ndushay 💬

@justinlittman the intent is to make it understandable; I didn't understand the CLI stuff at all. Maybe that's a documentation problem.

There is CLI documentation in the README: https://github.com/sul-dlss/sdr-client/#usage Maybe this misses the mark, though.

A primary design goal was for this to have as few dependencies as possible so that it can be easily distributed by gem install sdr-client and then it can be used as a CLI.

... where is it used for this? And should we keep supporting this?

We developed it so that we'd be prepared to meet the needs of campus users wanting direct SDR access (BLN & OpenNeuro were both suggested as potential partners). But the CLI's usage has been limited. I used it for a couple remediations---Catalhoyuk was the big one---and perhaps Andrew or Arcadia have used it as well?

FWIW, I do find sdr-client hard to reason about but the CLI isn't the part that I find most difficult. It's the fact that the client exposes all of its guts and expects the consumer to stitch together an interaction that makes sense. I do believe it was developed this way intentionally. But I also think it might be worth the time and effort to pause and do some analysis on how sdr-client is being used in hopes of perhaps improving the structure and maintainability of the code. Is that worth work cycle time now? I don't know.

[mjgiarlo]

Until we sort this out, I'm unassigning myself and backlogging this.

[andrewjbtw]

I use it fairly regularly, but mostly for getting Cocina. The client started out with pretty limited options that made it only marginally useful for testing and not useful for anything I did with production data. Even though the intent is for external users to make use of it, the message I got in workcycles and in planning for workcycles was that it wasn't a priority to develop it out that way. It may cover more of my needs now but I haven't had a chance to really put it to use. I have at least one issue to file related to my recent attempts to use it for test data because it still doesn't appear to fully handle access rights when depositing.

I used the Fedora 3 API a lot when we were on Fedora 3 and likely would use the SDR API for similar tasks. But for various reasons, including system architecture that isn't related to the API or client itself, it hasn't worked out that way yet.