On Sun, 2011-01-30 at 19:33 +0100, Stefano Bagnara wrote: > 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?).
(1) Multiple boolean parameters are confusing and considered a bad practice. (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. Cheers Oleg
