Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Received-SPF: error (nike.apache.org: local policy)
Message-ID: <1368706833.15509.6.camel@ubuntu>
Subject: Re: [DISCUSSION] make most of mime4j immutable
From: Oleg Kalnichevski <olegk@apache.org>
To: mime4j-dev@james.apache.org
Date: Thu, 16 May 2013 14:20:33 +0200
In-Reply-To: 
 <CAHVBJ+kO+-s36bLL1XFE0E06KhhBzrMZ02i5Yuf6_jo+vyhQHw@mail.gmail.com>
References: 
	<CAFvdMiAA31+6+6CVsC7OVhtOvgkhraDk_cLRZNrs25YfxUdd3Q@mail.gmail.com>
	 <1364328785.24203.5.camel@ubuntu>
	 <CAFvdMiDmUOtxxzjhyFnVnaSZJe12ymTCrtdk=mpR8rZ=rArGrg@mail.gmail.com>
	 <1368630670.27356.12.camel@ubuntu>
	 <CAHVBJ+=m43cUwK3d_EfKukhuotZ8OgdetvcwpXrWYdFsaM+rgw@mail.gmail.com>
	 <1368640741.3123.7.camel@ubuntu>
	 <CAHVBJ+=5s6tgUqZgt7ue_S+XLRutSAyVQE6W7JQ-e9TPeV+94Q@mail.gmail.com>
	 <1368701677.11979.1.camel@ubuntu>
	 <CAHVBJ+kO+-s36bLL1XFE0E06KhhBzrMZ02i5Yuf6_jo+vyhQHw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Thu, 2013-05-16 at 13:41 +0200, Stefano Bagnara wrote:
> 2013/5/16 Oleg Kalnichevski <olegk@apache.org>:
> > 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