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 Mon, 31 Jan 2011 09:43:05 GMT
On Mon, 2011-01-31 at 01:09 +0100, Stefano Bagnara wrote:

...

> >> I don't find the new method parse(InputStream, ParseParams,
> >> DecodeMonitor) very much appealing:
> >> 1) it uses a configuration object (ParseParams) just to pass 2
> >> booleans.. not a big gain over passing the 2 booleans (unless this
> >> time you used this class to support forward compatibility?).
> >
> > (1) Multiple boolean parameters are confusing and considered a bad
> > practice.
> > (2) We can easily add more parameters in the future without having to
> > change the interface itself
> 
> I see you often reference Pattern/Antipatterns/Bad practice.
> Don't you think that method with the "nullable" parameters had a bad smell, too?


In all honesty, I do not. I'll be more than happy to make ParseParams
non nullable, if that matters to you.

...

> 
> >> Now I moved to the other client project (a private one). In that
> >> project I was using entity.getDispositionType() and
> >> entity.getFilename() methods and I can't find them anymore: what is
> >> the right way to access this informations now?
> >
> > What is wrong with ContentDispositionField? If you are convinced these
> > two methods represent inherent properties of a MIME entity they should
> > be added to the Entity interface
> 
> So, just to be explicit, what you propose?
> Field f = entity.getHeader().getField(headername);
> if (f != null) {
>   if (f instanceof ContentDispositionField) {
>     String fileName = ((ContentDispositionFIeld) f).getFilename();
>     ....
>   }
> }

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.  


> Or something else?
> 
> >> This project does not
> >> use specific parsing configurations, but it uses a DecodeMonitor.. Do
> >> you API expect I use "null" as the ParseParam in the parse call or
> >> instead a "new ParseParam()" with no special change to the default
> >> config?
> >
> > Both approaches should have the same effect.
> 
> Do you like methods promoting the use of nullable parameters?
> 

I do not feel very strongly about it. Can take it either way. 

...

> 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.
Bringing mime4j back to HC is an appealing option, but not sooner mime4j
goes 1.0 GA.

Oleg



Mime
View raw message