[jira] [Assigned] (MIME4J-145) Improve organization of fields and fields parsers

["Oleg Kalnichevski (JIRA)" <mi...@james.apache.org>]

     [ 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