Stefano Bagnara wrote: > Bernd Fondermann ha scritto: > >> On 9/23/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: >> >>> robert burrell donkin-2 wrote: >>> >>>> this is the problem with lots of small patches: i don't understand >>>> where you are taking the design >>>> >>>> >>> In general, non-committers are expected to split their work up into smaller >>> patches, because it helps the reviewers. >>> >> Generally, yes. But if you'd like to present an alternative >> experimental design as a whole, we could as well grant you a sandbox. >> BTW, this would be the appropriate approach for such efforts even for >> committers. >> >> Bernd >> > > As far as I've understood until now the "whole new design" was from > Robert. Jochen patches are small performance improvement over the > current design. > > The main problem is that Jochen patches make it more difficult to keep > supporting the new design from Robert (or at least make the whole thing > less "clean") > > I don't know what design is better for mime4j and I didn't analyze the > patches in depth to judge their quality. What I can tell is that Jochen > patches serve a specific concrete purpose (commons-upload integration > and its needed capabilities) while I feel Robert ones more abstract. I > guess Robert "design" is related to specific IMAP usage, so it would > probably help (me) to understand what IMAP features are involved by this > design decisions (and how). > > Ignoring the technical/design issue I think at this time it is better > for mime4j to increase its community/acceptance by helping other > projects (e.g. commons-upload) to use mime4j. IMHO collecting users that > depends on the library is the best thing to ensure that future design > choices will satisfy anyone needs. > > At the same time, we should try to be our first users with JAMES Server > but we currently don't use it. If Robert design is a prerequisite to be > able to use mime4j in the IMAP implementation then this worth discussing > more. > > I'd also like to know what Niklas Therning thinks about this issue. He > is one of the original authors and probably one of the few current users > of this library. > We're using MimeStreamParser only and as long as the way that works doesn't change too much we will be happy. In our POP3, IMAP and SMTP proxies we're using NIO (Apache MINA) and ByteBuffers all over the place so I guess we could maybe some day in the future have use for non-streaming parsing. But I think that's quite unlikely.
I must admit I haven't had the time to understand this discussion completely. I would certainly like to see commons-fileupload use mime4j so I think we should try to accommodate Jochen's needs. It appears to me that those needs would be satisfied by resolving MIME4J-27 and MIME4J-30. As Robert says in one of the first comments on MIME4J-30 he could look into producing an alternative patch which resolves that issue while still keeping the current design. IIUC that would both solve Jochen's problems and still let Robert use mime4j the way he wants. Am I missing something here? -- Niklas Therning www.spamdrain.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
