Then the right approach to me would be to use the DOM API and provide a suitable StorageProvider leveraging your use case.
For instance https://github.com/apache/james-mime4j/blob/master/storage/src/main/java/org/apache/james/mime4j/storage/TempFileStorageProvider.java -- Best regards, Benoit TELLIER General manager of Linagora VIETNAM. Product owner for Team-Mail product. Chairman of the Apache James project. Mail: btell...@linagora.com Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) On Sep 13, 2023 3:31 PM, from Rajdip Ghosh Hi Benoit, I greatly appreciate your swift response and the proposed solution to enhance byte position tracking in BufferedLineReaderInputStream within Mime4j. I will try your suggestion to modify BufferedLineReaderInputStream to monitor consumed bytes and implement an int getPosition. Here's a summary of your recommended actions that I'll be undertaking: - Initiating a ticket related to this enhancement on the Mime4j JIRA project: issues.apache.org/jira/projects/MIME4J. - Preparing a Pull Request (PR) for your GitHub repository to propose the necessary changes Regarding your curiosity about our use case for this byte position tracking, let me provide some context. We intend to utilize this feature to determine the startByteLocation and noOfBytes for each part of the MIME content. Our approach involves storing the EML file once on disk, and during reads, we will load data as per the client's request. Here's how we plan to utilize it: If a client requests specific sections, such as the email body, we'll fetch only those bytes and pass them to the respective data handler. In essence, this byte position tracking empowers us to optimize data retrieval, enhancing efficiency while minimizing unnecessary data transfer. Once again, thank you for your invaluable support and guidance. Regards, *Rajdip Ghosh* Mob: +91-90088-34500 Email ID: rghosh...@gmail.com On Tue, Sep 12, 2023 at 8:14 PM Benoit TELLIER <btell...@linagora.com> wrote: > Hello, > > This feature is not currently supported. > > I think the most straight forward possibility is to > modify BufferedLineReaderInputStream so that it tracks the number of bytes > it consummed. MimeTokenStream could then leverage an int getPosition method > using the position within the rootentity. > > We would likely welcome warmly such a contribution. > > -> You can open a ticket related to this on our JIRA: > issues.apache.org/jira/projects/MIME4J > -> You can fire a PR on our Github > > I'm curious to know: what is your use case with this position? > > > > -- > > > Best regards, > > > > Benoit TELLIER > > > > General manager of Linagora VIETNAM. > > Product owner for Team-Mail product. > > Chairman of the Apache James project. > > > > Mail: btell...@linagora.com > > Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) > > > On Sep 12, 2023 9:17 PM, from Rajdip Ghosh Hello Mime4j Dev Team, > > I hope this message finds you well. I am currently working with Mime4j and > have a question regarding obtaining the exact byte start and end pointer of > each EML part while using MimeTokenParser. > > It seems that MimeTokenParser doesn't provide a direct way to retrieve the > byte pointer. My research has shown that MimeEntity internally uses > BufferedLineReaderInputStream, which utilizes a cyclic buffer and > prefetches data from the provided input stream (EML as Stream). > Unfortunately, using PositionInputStream has not been helpful in this > context. > > I would greatly appreciate it if someone could provide guidance on how to > accurately determine the byte pointer of an EML file when processing it > with MimeTokenParser. Any insights or alternative approaches would be > immensely helpful. > > Thank you in advance for your assistance, and I look forward to your expert > advice on this matter. > > Regards, > *Rajdip Ghosh* > Email ID: rghosh...@gmail.com > > >
