Skip to content

Replace NetworkService with HttpClient in LCP#794

Open
stevenzeck wants to merge 3 commits into
readium:developfrom
stevenzeck:refactor/lcp-network-service
Open

Replace NetworkService with HttpClient in LCP#794
stevenzeck wants to merge 3 commits into
readium:developfrom
stevenzeck:refactor/lcp-network-service

Conversation

@stevenzeck
Copy link
Copy Markdown
Contributor

This PR replaces the usage of NetworkService with HttpClient in the LCP module.

Related to #779.

Comment thread readium/lcp/src/main/java/org/readium/r2/lcp/license/License.kt Outdated
Comment thread readium/lcp/src/main/java/org/readium/r2/lcp/service/LicensesService.kt Outdated
}
}
Try.success(
HttpFetchResponse(response.response, ByteArray(0))
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why you return an empty ByteArray. You could return nothing. Besides, the error handling is a bit simplistic. That might be perfectionism, but in case of a filesystem error, we shouldn't fail with an HttpError. I would rather introduce an HttpDownloadError which could be either an HttpError or a FilesystemError.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a HttpDownloadError sealed class in HttpError and followed the naming pattern in the latter: HttpDownloadError.Http and HttpDownloadError.Filesystem. I'm wary about naming conventions, as we already have an HttpError class. And there are a lot of files and classes already with the same name, which gets confusing and causes conflicts that have to be addressed.

Could also make HttpDownloadError an interface that HttpError implements, but that might be crossing boundaries a bit too much.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And there are a lot of files and classes already with the same name, which gets confusing and causes conflicts that have to be addressed.

Could you elaborate on this?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's nothing specific to this PR. One example is Encryption in Shared and in LCP. There's a similar one with Link.

I think most of it is older stuff, but don't want to add to it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok! I think it's fine to have different types as they conform to different specifications. Even if they currently match, they might diverge at some point.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah having different types as fine, I'm more against the same naming.

@stevenzeck stevenzeck requested a review from qnga June 1, 2026 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants