Return-Path: Delivered-To: apmail-james-mime4j-dev-archive@minotaur.apache.org Received: (qmail 80436 invoked from network); 7 Feb 2009 12:03:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Feb 2009 12:03:26 -0000 Received: (qmail 95157 invoked by uid 500); 7 Feb 2009 12:03:26 -0000 Delivered-To: apmail-james-mime4j-dev-archive@james.apache.org Received: (qmail 95138 invoked by uid 500); 7 Feb 2009 12:03:26 -0000 Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: mime4j-dev@james.apache.org Delivered-To: mailing list mime4j-dev@james.apache.org Received: (qmail 95127 invoked by uid 99); 7 Feb 2009 12:03:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Feb 2009 04:03:26 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Feb 2009 12:03:23 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 0C60B234C4A9 for ; Sat, 7 Feb 2009 04:03:02 -0800 (PST) Message-ID: <2055058419.1234008182034.JavaMail.jira@brutus> Date: Sat, 7 Feb 2009 04:03:02 -0800 (PST) From: "Markus Wiederkehr (JIRA)" To: mime4j-dev@james.apache.org Subject: [jira] Commented: (MIME4J-114) Efficient Read Access To Parts Of A Parsed Document In-Reply-To: <722084937.1233995339576.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/MIME4J-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671456#action_12671456 ] Markus Wiederkehr commented on MIME4J-114: ------------------------------------------ Retrieving the byte offset from the underlying input stream might be tricky since Mime4j uses a few buffers when parsing a message. I'm not saying it is impossible of course. Inner transfer encodings are something else to consider. Let's say you had a message that contains another (maybe forwarded) message in base64 encoded form. That inner message can of course also have parts that are transfer encoded themselves. A byte offset alone does not help with retrieving parts of the inner message. > Efficient Read Access To Parts Of A Parsed Document > --------------------------------------------------- > > Key: MIME4J-114 > URL: https://issues.apache.org/jira/browse/MIME4J-114 > Project: JAMES Mime4j > Issue Type: Wish > Affects Versions: 0.6 > Reporter: Robert Burrell Donkin > Fix For: 0.7 > > > Use Case > -------------- > Consider a large MIME document stored (as a single document) in a medium which allows random access to the bits (for example, a BLOB in a data store or a file.) > I parse the document once using Mime4J and store the meta-data (for example, in a data store) so that I can read this data many times without loading and reparsing this large document > I wish to be able to read efficiently a part of the document without loading the whole, and this may happen frequently -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.