james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: DOM API refactoring completed
Date Tue, 08 Feb 2011 15:17:13 GMT
On Tue, 2011-02-08 at 11:58 +0100, Stefano Bagnara wrote:
> 2011/1/31 Oleg Kalnichevski <olegk@apache.org>:


> > In all honesty, I do not. I'll be more than happy to make ParseParams
> > non nullable, if that matters to you.
> I took some time to better think about it.
> I'm convinced that parse(InputStream,ParseParams,DecodeMonitor)
> doesn't make sense.
> My main explanation is that I have just 2 use cases and:
> 1) uses ParseParams but doesn't use DecodeMonitor
> 2) uses DecodeMonitor but doesn't use ParseParams.
> I also think they are common use cases. Just thinking about it:
> - you use DecodeMonitor to be informed of malformations or to force
> strict mode parsing (for validation) or to be informed for bad
> encodings
> - you instead use ParseParams when you don't want to recurse into
> parts or you don't want to decode.
> So I see that most users will need one or the other but rarely needs
> both at the same time.
> Is there a way (that you would accept) we can pass ParseParams and
> DecodeMonitor to the Builder or (even better) to the Factory so that
> we can still use parse(InputStream)?

I have no problem with that of what so ever. In the initial version of
MessageBuilder had abstract setters for those three attributes (decoder
monitor, content decoding and flat mode). I could not see a good reason
why those attributes warranted a special treatment. I decided to keep
the original design nevertheless but changed those setters to method
parameters, which I felt was more logical.

> >
> > It is not something I propose. This is the way mime4j always worked with
> > structured headers.
> >
> > Let me repeat my question. Do you think #getDispositionType()
> > #getFilename() methods represent inherent properties of a MIME entity
> > that apply to all its instances? If so, those methods should be added to
> > the Entity interface. If not, having to use the lower level API to
> > access structured fields is the price to pay for not polluting the
> > higher level API with methods relevant only for a subset of implementing
> > classes.
> Yes, we are "mime4j" so we should expose mime stuff to make it easier
> to deal with mime.
> It is part of an old and estabished standard tracked rfc (rfc2183).
> My main concern is with the API forcing the user to use class casting
> to extract a "basic" information about the mime content.
> I'm not sure I understand why you removed it during your refactoring:
> was it because of "technical issues" or because didn't like to expose
> that stuff?

Honestly, I felt those methods did not represent generic properties of
an entity. No problem, I'll add them to the Entity interface.

> >> So, why are you still interested in mime4j? Is there another project
> >> depending on it or anyway you plan to reintroduce mime4j in HC after
> >> the changes?
> >> I'm just trying to see your use case.
> >>
> >
> > I use mime4j for private projects, mostly low level 'core' code, though.
> Do you use the dom module or just the core module?
> In the first case, do you use full "structured"/"decoded" parsing or
> other features like headless parsing, flat parsing, non-decoded
> contents and so on?

I use both core and dom, but I personally need only a subset of dom
functionality: field parsers and basic DOM to build messages from
scratch. I have not used mime4j to modify existing messages.


View raw message