2013/5/16 Oleg Kalnichevski <[email protected]>: > On Thu, 2013-05-16 at 10:59 +0200, Stefano Bagnara wrote: >> With a similar refactoring you are telling that everyone will be moved >> to a "all in memory parsing" unless they add support for storage >> manager in their applications/libraries. > > This is the default mode already.
I know this, but a new release could have included a "fallback to filesystem over 100KB" strategy by default and the current users wouldn't need to change a thing. But maybe we won't ever do a similar thing by default, so you're convincing me ;-) > That would not need to change. Lazy parsing would not need to go away. I don't get how you do both immutable and lazy, but if we can keep lazy parsing then my main argument goes away and I'm happy to follow your changes! > Also, I was expecting DOM API to evolve to become bidirectional, so I >> could simply parse a message, add an attachment and serialize it again >> or change the encoding of a part and serialize it again... > > Create a builder, build a message, serialize the message, mutate the > builder, create another message, serialize that message, repeat if > needed. Let me know if I understood: Let's say I want to just alter the 99th part of the 3rd level of a big nested mime message so that it is encoded as base64 instead of uuencoding: in a mutable API I simply do ---- message[part1][part4][part2][content-transfer-encoding] = 'base64'; ---- With immutability ---- build a new message (output) start traversing the input message (input) unless I'm on "part1.part4.part2" path I simply copy the input in output. As soon as I reach "part1.part4.part2" I create a new part using the base64 encoding. continue with my traversing "clone" ----- For "trivial" changes this is a lot more work, unless the "mutator" is really smart doing this for you. To be honest, you usually already traverse messages to *find* the things you want to change, so my comparison is not so fair. > In any heavy duty application one would undoubtedly need to deal with > large content entities and store them appropriately, but in my opinion > mime4j DOM is used way more to build messages from scratch rather than > to parse and modify messages. Streaming API is better for parsing > messages. Hence my conviction that the current resource management model > is geared more toward a minority of the user population at the expense > of a majority. In my case I always used the dom api for parsing and having a simpler interface than the parser one. The current api was not complete enough to be used to build messages, IMHO. > I do not use mime4j DOM much myself. I am quite OK with leaving things > as they currently stand. I suggested you should proceed with the changes you proposed: as I already wrote I trust your skills and from your answers I see we share the goals (keep lazy parsing, let people use dom api to build messages), so there's no reason I should stop you from improving mime4j! :-) And just to be sure the are no misunderstanding: in my opinion you can simply continue to work in SVN even without answering this message! Code is the best answer, sometimes, and I'm sorry I submit too few code and too much mailing list posts ;-) Power to active committers! Stefano
