On Thu, 2013-05-16 at 13:41 +0200, Stefano Bagnara wrote: > 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 ;-) >
The reason why we ought not do it by default is to ensure the user is aware of implications of having content overflowing to a temporary persistent storage potentially accessible by other users, processes, etc. > > 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! > A volatile flag may need to get flipped but as far as the consumer is concerned the object remains in _exactly_ the same state as before. > > 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! I'll be on vacation next week and likely to get sucked in by HC related stuff afterwards. We'll see where we stand in a few months. Oleg
