dicom.Parse should not require the byteToRead parameter

[flicaflow]

Hello everyone,

dicom.Parse requires to provide the bytes to read. This is rather unpractical if the caller has a io.Reader at hand. The only way to handle this is buffering the whole stream before calling Parse which just wastes memory.

Maybe I don't have the complete picture and don't understand why this is necessary. However I have a couple of suggestions how to deal with this.

1. When the Parser reaches the end of file prematurely it could return an io.EOF at least have it checkable by errors.Is(err,io.EOF) this would allow the caller to decide whether the outcome is acceptable of not, the byteToRead could then be handles as the upper bound to read.
2. bytesToRead = 0 , could be defined as read until EOF , Parse would only return an error when EOF occures inside an element
3. getting rid of bytesToRead would be the cleanest. However changing the signature should not be taken lightly. And as I said before I don't know if this not required to have in certain scenarios

My opinion is the option 2 would be the best solution while option 1 would be the easiest to implement.

I'm happy to help with a PR if we find a solution and thanks for the great work!!

[suyashkumar]

Yep I think this is a reasonable and something I've thought a little about in the past. I think the bytesToRead has been there largely for historical reasons that have to do with the way we use limits in the dicomio.Reader. Will need to take a closer look to see if we can cleanly move away from a bytesToRead given our current state but I think it's probably doable.

One thing I'll mention is that with a file, getting the total number of bytes is easily doable without buffering the whole file: see https://pkg.go.dev/os#File.Stat. That being said, moving away from bytesToRead is probably the best option and accommodates io.Reader more broadly (e.g. network requests etc).

[suyashkumar]

Closed with the changes in #273!