Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better support for range requests #1

Closed
yagee-de opened this issue Oct 1, 2019 · 5 comments
Closed

Better support for range requests #1

yagee-de opened this issue Oct 1, 2019 · 5 comments

Comments

@yagee-de
Copy link

yagee-de commented Oct 1, 2019

For large video or PDF files I need to response to range requests.
OcflObjectReader should allow access to physical Path on the underlying filesystem to allow efficient handling of those requests.

@pwinckles
Copy link
Collaborator

How about I modify the FileDetails object that's returned as part of a describeObject/describeVersion request to include the path to the file relative to the storage root?

For example, let's you have object obj123 and v1 of the object contains the file dir1/file1.mov. The FileDetails object in this case would look something like the following:

{
  "filePath": "dir1/file1.mov",
  "storagePath": "obj123/v1/content/dir1/file1.mov",
  "fixity": {
    "sha512": "..."
  }
}

Would that work for you?

@yagee-de
Copy link
Author

yagee-de commented Oct 2, 2019

Hi this sounds like a way to go, but I need to get the storage path of obj123 via ObjectDetails and/or via OcflRepository. In the end I need an absolute path to serve the content, so handling with the triple of OcflRepository, ObjectDetails and FileDetails could make the code ugly. Maybe all three could implement an Interface e.g. PathResolveable with two methods Path getRelativePath() and Path getAbsolutePath()?

@pwinckles
Copy link
Collaborator

I cannot add absolute paths to the API because this does not make sense for all implementations, such as the Amazon S3 implementation that I recently started working on.

Just so I'm sure we're on the same page, there are three paths of interest.

  1. Storage root path: The path to the OCFL storage root directory that contains all of the objects.
  2. Object root path: The path from the storage root to the root directory of an object. In the case of the ocfl-java library, this path is dictated by the ObjectIdPathMapper that is used.
  3. File path: The path from the object root to the file's location within a version's content directory.

In the FileDetails solution that I purposed, storagePath is the equivalent of objectRootPath/filePath. That is to say, it is the path to a file within an object relative to the storage root. (As an aside, this value is also the key that the file is stored under in S3.) All your code would need to do is resolve the storagePath with the path to the storage root.

@pwinckles
Copy link
Collaborator

Commit 6144f4f adds storagePath to FileDetails.

@pwinckles
Copy link
Collaborator

I'm going to close this issue. ocfl-java does support retrieving files via InputStream. Feel free to re-open if you have more to say.

pwinckles pushed a commit to pwinckles/ocfl-java that referenced this issue Jul 15, 2024
tweak size digest algorithm implementation
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

No branches or pull requests

2 participants