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.
At the moment everything we saw supports the following statements for the TIFed files:
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 -= 12for 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.