Hi all, as you saw I worked on the cycleclean branch for some day.
If anyone have the time to review I'd like to collect thoughts on what I did, to understand if you like the direction or not, and, in case you like it, if you think that the branch should merge before releasing 0.7 or after. (IMHO it is already better than trunk and the whole refactoring should happen in trunk, but I'm happy to work in branches when I'm not able to describe my ideas with long discussions). Please note that the branch should be considered work in progress (expecially wrt package names). Also I have concerns about dom manipulation. In the branch I extracted the dom to 4 packages (message, field, field.address, field.datetime). As you see the dom has no dependency on other mime4j packages nor on commons-logging. An user could build a message from scratch without parsing it using the DOM. Currently whenever the user adds a field, mime4j does something "weird" 1) create a raw representation of the field to be added (Field.someMethod) 2) lazily parse the raw representation to a ParsedField implementation. 3) if the user try to get back the data it is parsed again. Isn't it a bit "unintuitive"? Then, the current lazy parsing and ParsedField interface "contract is: 1) you create a lazy parsed field, you never get an exception for this. 2) the first time you try to access a field property the field is lazily parsed. again you don't get notification for parsing issues, but simply a null value, like you get if the field did not have that specific parameter you are reading. 3) you have isValid() and getException methods to query the field object for parsing issues. Again, this doesn't seem intuitive to me... I didn't worked out solutions yet, but I'd like to collect your opinions and ideas on this to avoid diverging too much from the community directions. Stefano
