james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ioan Eugen Stan <stan.ieu...@gmail.com>
Subject Re: [DISCUSSION] make most of mime4j immutable
Date Tue, 14 May 2013 11:22:01 GMT
Nice API Oleg!  Looks very good.

On Tue, May 14, 2013 at 2:11 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Mon, 2013-05-13 at 21:20 +0200, Stefano Bagnara wrote:
>> 2013/5/13 Oleg Kalnichevski <olegk@apache.org>:
>> > I am about to take the first cut at the DOM API redesign. If no
>> > objections are raised I am planning to do it on trunk and _without_
>> > preserving backward compatibility with 0.7. If you would rather prefer
>> > me to work on a branch (or keep deprecated 0.7 DOM APIs in place) please
>> > do let me know.
>>
>> +1 to work in trunk: branches are only an overhead when there is a
>> single active developer ;-)
>>
>> > I also would like to make MimeConfig immutable which cannot be done
>> > without breaking API compatibility. Please complain loudly if you think
>> > it is not OK.
>>
>> When you say immutable do you mean you want to move everything from
>> setters (8 properties) to a long list of constructor arguments? Or
>> something else?
>>
>> I hope to find some time to test the updated code against my products
>> and report any broken use case, if any, before 0.8 release so we can
>> fix them.
>>
>> Not sure what you're going to do, but please take into consideration
>> the way we use MimeConfig in jDKIM:
>> -----
>>     private MessageServiceFactory newMessageBuilder() throws MimeException {
>>         MimeConfig mec = new MimeConfig();
>>         mec.setMaxLineLen(10000);
>>         mec.setMaxHeaderLen(30000);
>>
>>         MessageServiceFactory mbf = MessageServiceFactory.newInstance();
>>         mbf.setAttribute("MimeEntityConfig", mec);
>>         mbf.setAttribute("FlatMode", true);
>>         mbf.setAttribute("ContentDecoding", false);
>>
>>         return mbf;
>>     }
>> -------
>> Here is another use case where I used MimeConfig in a customer project:
>> -------
>> MimeConfig mimeEntityConfig = new MimeConfig();
>> mimeEntityConfig.setStrictParsing(false);
>> mimeEntityConfig.setMaxLineLen(10240);
>> MessageServiceFactory factory = MessageServiceFactory.newInstance();
>> factory.setAttribute("StorageProvider", new MemoryStorageProvider());
>> factory.setAttribute("MimeEntityConfig", mimeEntityConfig);
>> factory.setAttribute("DecodeMonitor", new CheckHandlerDecodeMonitor(eh));
>> MessageBuilder builder = factory.newMessageBuilder();
>> Message message = builder.parseMessage(is);
>> ------
>> And I also attach another snippet using MimeConfig, too.
>>
>> I don't expect everything to remaing unchanged and of course I'm ready
>> to update my code to mime4j changes, but I prefer to report the use
>> cases in advance, for reference.
>>
>> If you prefer to commit the changes before explaining what is your
>> plan with MimeConfig immutability please go ahead (maybe it's easier
>> for you to commit the change than explaining it).
>>
>> Stefano
>
> Stefano
>
> With the new API the same config code would look like
> ---
> MimeConfig mec = MimeConfig.custom();
>   .setMaxLineLen(10000)
>   .setMaxHeaderLen(30000)
>   .build();
> ---
> The benefit of having immutable config is that the same object can be
> passed around without a risk of some component altering the config at
> runtime and impacting other components or having to create a clone each
> and every time. So, instead of creating new instances of MimeConfig with
> default settings one can use MimeConfig#DEFAULT or MimeConfig#STRICT.
>
> One can alter an existing MimeConfig instance by doing that
> ---
> MimeConfig mec = MimeConfig.copy(MimeConfig.STRICT);
>   .setMaxLineLen(10000)
>   .setMaxHeaderLen(30000)
>   .build();
> ---
>
> Oleg
>



-- 
Ioan Eugen Stan
0720 898 747

Mime
View raw message