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: DOM API refactoring completed
Date Sun, 30 Jan 2011 19:48:10 GMT
On Sun, 2011-01-30 at 19:33 +0100, Stefano Bagnara wrote:
> 2011/1/28 Oleg Kalnichevski <olegk@apache.org>:
> > Folks
> >
> > I did my best to improve the DOM API and to fix things what I felt were
> > inconsistent while largely preserving the original design of Stefano.
> I tried to update jDKIM and my internal project but I see it is taking
> a bit more than I thought, so I need some more time.
> I don't find the new method parse(InputStream, ParseParams,
> DecodeMonitor) very much appealing:
> 1) it uses a configuration object (ParseParams) just to pass 2
> booleans.. not a big gain over passing the 2 booleans (unless this
> time you used this class to support forward compatibility?).

(1) Multiple boolean parameters are confusing and considered a bad
(2) We can easily add more parameters in the future without having to
change the interface itself

>  Also, we
> already have a configuration object for parsing and it is
> MimeEntityConfig.. so it seems to be confusing to have 2 configuration
> objects (one in the "public" package and one in the "private" package,
> but I'm not even sure you consider "message" a private package) (Also
> maybe ParseParam.flatMode shouldn't be "true" by default).
> 2) I'm not a fan of nullable parameters and in jDKIM I would instead
> have to use this method using a new ParseParams and null as decode
> monitor (the use of parsing parameters and the use of a decode monitor
> are not related in any way, instead I this most users won''t use them
> together: if you disable content decoding and use flat mode then you
> don't probably expect a lot to be "DecodeMonitored").
> So, for jDKIM the latest changes are not so appealing to my eyes

No problem. I'll happily revert to the 0.6 API if you like it better
that way.

>  (I'm
> writing this mainly because I hope I completely missed your
> "consistency" changes and there is a much better way to refactor jdkim
> and I don't see it as I'm still "limited" on my reasonings of the
> previous design: I know this happens, so I'm asking for some hints.).

Not very surprising since you refused to see any consistency issues in
the first place.

> Now I moved to the other client project (a private one). In that
> project I was using entity.getDispositionType() and
> entity.getFilename() methods and I can't find them anymore: what is
> the right way to access this informations now? 

What is wrong with ContentDispositionField? If you are convinced these
two methods represent inherent properties of a MIME entity they should
be added to the Entity interface 

> This project does not
> use specific parsing configurations, but it uses a DecodeMonitor.. Do
> you API expect I use "null" as the ParseParam in the parse call or
> instead a "new ParseParam()" with no special change to the default
> config?

Both approaches should have the same effect.

> > Please review and let me know if you approve or disapprove.
> I shown the jDKIM use case but I would love to consider also other use
> cases so to be able to have a more complete understanding about how
> the refactored api compares to the previous one.
> IIRC you use mime4j in Http components. Have you already tried
> upgrading HC to use the latest trunk?

I had to drop the dependency on mime4j approximately 6 months ago
because mime4j development was basically in limbo. 



View raw message