2011/1/28 Oleg Kalnichevski <[email protected]>: > 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 config? > 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. Stefano
