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

Consider keeping Tape Image Header information #372

Open
achaikou opened this issue May 11, 2021 · 0 comments
Open

Consider keeping Tape Image Header information #372

achaikou opened this issue May 11, 2021 · 0 comments

Comments

@achaikou
Copy link
Contributor

At the moment everything we saw supports the following statements for the TIFed files:

  • dlis:
    Every VR is wrapped in a TM. There are no TMs inside VR data.
  • lis:
    Every PR is wrapped in a TM. There are no TMs inside PR data.

These observations might help us read more files than we do now (#370 , #371)

Giving more weight to TMs might create difficulties in our code, which have to be considered beforehand:

  • LFP library was designed with a goal of abstracting away any intermediate protocols. Explicitly caring about TM record length destroys that purpose.

    (Possible redesign note: we couldn't implement RP66 LR protocol and LIS79 PR protocol within that library because we need information from the headers and LFP discards that information on purpose. So we might want to keep in mind the idea to search for a way to abstract away all protocols while being able to access required data regardless)

  • By using LFP library we need to pay attention to whether file is TIFed or not only in load. In all other places in dlisio LFP takes care of it for us. So explicitly dealing with information from TIFed files might create different code paths for TIFed and non-TIFed files, thus adding complexity.

    (Possible redesign note: we still have to do some not very nice adjustments aka offset -= 12 for TIFed files in load. LFP library doesn't help us with that. Can this be changed?)

If this issue is picked up, major thought in general should be given to the current use and design of LFP as it essentially is the core of the issue.

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

1 participant