On Sat, Jan 10, 2009 at 9:33 PM, Markus Wiederkehr <markus.wiederk...@gmail.com> wrote: > On Sat, Jan 10, 2009 at 10:27 PM, Robert Burrell Donkin > <robertburrelldon...@gmail.com> wrote: >> On Sat, Jan 10, 2009 at 8:05 PM, Markus Wiederkehr >> <markus.wiederk...@gmail.com> wrote: >>> On Sat, Jan 10, 2009 at 4:34 PM, Robert Burrell Donkin >>> <robertburrelldon...@gmail.com> wrote: >>>> what about https://issues.apache.org/jira/browse/MIME4J-6? >>>> >>>> should this be addressed? closed? moved to 0.7? >>> >>> I don't like the idea very much. Not that it wouldn't be nice to have >>> but the necessary changes in Mime4J would be too drastic in my >>> opinion. >>> >>> I think the idea behind this issue is to improve performance. I wonder >>> if that's even possible considering that it would require two passes >>> to fully parse a message. >>> >>> Also not every InputStream is capable of telling the current position >>> and seeking to a position and opening a new InputStream from there >>> (the basic idea behind JavaMail's SharedInputStream). So in many cases >>> it would be necessary to copy the message to a storage that is capable >>> of creating such special input streams before parsing. This would >>> further degrade performance. >>> >>> And last but not least I think Stefano's comment on potential nested >>> encodings is a valid concern. >> >> AIUI this is related to concerns about memory usage for big documents >> but i'm not sure that the proposal is the best solution > > That's what StorageProvider is for IMO.
there are some potential sem-DOM use cases upstream in the protocols (IMAP, NNTP) and potentially also in mailet 3 but let's leave this till after the 0.6 release. probably worthwhile analysing these use cases and seeing whether StorageProvider completely satisfies them. this can be reviewed at the same time. >> i'm tempted just to move to 0.7 for the moment > > Fine by me.. done - robert --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org