james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <mime4j-...@james.apache.org>
Subject [jira] [Assigned] (MIME4J-145) Improve organization of fields and fields parsers
Date Thu, 31 Mar 2011 08:25:06 GMT

     [ 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

View raw message