james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [DISCUSSION] make most of mime4j immutable
Date Tue, 14 May 2013 11:11:55 GMT
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


Mime
View raw message