Hi Stefano, comments inline...
2010/1/5 Stefano Bagnara <[email protected]>: > Hi all, > > as you saw I worked on the cycleclean branch for some day. Yep, I noticed ;) > > 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). I'm +1 to merge it to trunk and continue there with the development. I'm also +1 to get all the refactoring done before cut 0.7. The only thing I would like to see is some documentation which describe the changes so the "users" know what todo to "fix" their code for new mime4j. > > 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. Yeah the new dependency graph looks very promising. I think the commons-logging should get removed everywhere and just let the user inject his own Logger like we did with jSPF. Maybe we can ship some Logger implementation which use 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"? Yeah it is. I think parsing should get done only one time... > > 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... Yep, I agree but I don't have any idea about howto "fix" this. > 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 > Bye, Norman
