On Tue, 2011-02-08 at 11:58 +0100, Stefano Bagnara wrote: > 2011/1/31 Oleg Kalnichevski <[email protected]>:
... > > 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. Oleg
