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] [Resolved] (MIME4J-145) Improve organization of fields and fields parsers
Date Tue, 05 Apr 2011 16:18:05 GMT

     [ https://issues.apache.org/jira/browse/MIME4J-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Oleg Kalnichevski resolved MIME4J-145.
--------------------------------------

    Resolution: Fixed

Problem 1) 
--------------
resolved, if I am not mistaken

Problem 2) 
--------------
resolved, if I am not mistaken

Problem 3) 
--------------
* Moved (pretty much) all low level code that deals with splitting raw fields into name /
value pairs into one class (RawFieldParser)
* RawFieldParser code has been optimised to reduce the amount of intermediate garbage generated
during the splitting process. Ultimately I would like to try to reduce intermediate garbage
to almost zero
* DefaultBodyDescriptor is in core and therefore it cannot make use of dom level field parsers.
Some functionality duplication seems unavoidable.

Oleg

> 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

Mime
View raw message