[
https://issues.apache.org/jira/browse/MIME4J-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski reassigned MIME4J-145:
----------------------------------------
Assignee: Oleg Kalnichevski (was: Stefano Bagnara)
> Improve organization of fields and fields parsers
> -------------------------------------------------
>
> Key: MIME4J-145
> URL: https://issues.apache.org/jira/browse/MIME4J-145
> Project: JAMES Mime4j
> Issue Type: Improvement
> Affects Versions: 0.6
> Reporter: Stefano Bagnara
> Assignee: Oleg Kalnichevski
> Priority: Minor
> Fix For: 0.7
>
>
> I'd like to fix some issue in the organization of fields and field parsers
> asap, while we are still on "low" (0.x) release numbers.
> One thing is to remove DefaultFieldParser knowledge in AbstractField, another
> would be to reorganize things so that parsing of headers is done in a single
> place. Currently we have some parsing in Fields, some parsing in
> MaximalBodyDescriptor, some parser use the DefaultFieldParser, some other
> code instead directly instantiate the AbstractField instance.
> One more thing is parsing of raw headers: we have 2 different logic to do the
> same thing. Once in RawBody where we do one thing to extract name and body,
> and once in DefaultFieldParser.parse(final ByteSequence raw), where we do
> different things. E.g: the first simply locate the ":" and do not remove any
> starting space from the body, the second instead has a regexp matching valid
> header names and remove the starting space from the body.
> Last one is MimeUtil.getHeaderParams, a parser that will parse header
> parameters. It is used by MaximalBodyDescriptor.parseContentDisposition and
> by DefaultBodyDescriptor.parseContentType. At the same type we have
> ContentTypeParser and ContentDispositionParser classes also doing parsing for
> that headers. Why do we have 2 implementations for the parsing of the same
> headers?
> Is there a logic behind this or is this simply the result of years of
> different hands and refactorings and we simply should fix it?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
