james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: DOM API refactoring completed
Date Sun, 30 Jan 2011 18:33:55 GMT
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?). 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 (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.).

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? 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

> 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 also have a local branch of James IMAP upgraded to the "old" mime4j
trunk: I will try to find some time to update that code to latest
trunk in the next days so to have a better overview.

About storage changes I will start a new thread.


View raw message