james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <norman.mau...@googlemail.com>
Subject Re: [cycleclean] branch review and questions
Date Wed, 06 Jan 2010 10:35:55 GMT
Hi Stefano,

comments inline...

2010/1/5 Stefano Bagnara <apache@bago.org>:
> 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

Mime
View raw message