Eduardo Pinho

That was nearly the whole idea behind it! A lazy DICOM object would keep track of the byte offset of larger elements from a data source and only fetch them...

> Sorry, I meant the `DicomObject` implementation. What I am getting at is that I think we should rename the current `InMemDicomObject` to `StandardDicomObject`, and have it serve all purposes....

I think we're getting closer to common grounds, hang in there! > Is there something beyond a match case for the `Loaded(PrimitiveValue)` or `Unloaded(Token)` values? Maybe I'm missing something, but...

> Back to your previous point about RefCell performance, couldn't we work with the AttributeEntry trait to also ensure that if a value is eagerly loaded, that no interior RefCell...

Lazy loading of any DICOM file is one of the topics I wish to tackle next, as this inevitably requires a bit of tweaking in nearly all crates of the...

@pauldotknopf This is next in my work queue, so I would like to keep you informed in case there was any eventual progress on your end or concerns you would...

@eseaflower Thank you for reaching out. I have some developments in a separate branch for an alternative parser, but an implementation of a DICOM object with lazy losing is still...

With #126 merged, work for an implementation of a lazily loaded DICOM object has gone one step further. A look-up table of byte positions will be built alongside the first...

Thank you for reporting. Yes, it makes sense to continue extending the project's network tool repertoire. And that reminds me that these tools could be accompanied with a high-level API....

So, the way to fulfil the C-FIND protocol from the SCU end would be: 1. Send a C-FIND-RQ message http://dicom.nema.org/medical/dicom/current/output/chtml/part07/sect_9.3.2.html 2. Send a DICOM query in compliance with the DIMSE-C...