james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject [cycleclean] branch review and questions
Date Tue, 05 Jan 2010 19:33:21 GMT
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

Mime
View raw message