james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefano Bagnara (JIRA)" <mime4j-...@james.apache.org>
Subject [jira] Commented: (MIME4J-156) DOM (message) classes should not be implementation specific. Move implementation to a different package (message.impl)
Date Sat, 02 Jan 2010 17:31:54 GMT

    [ https://issues.apache.org/jira/browse/MIME4J-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795874#action_12795874
] 

Stefano Bagnara commented on MIME4J-156:
----------------------------------------

Let's talk about the DOM.

The current solution is the "message", "field", "field.address" and "field.datetime" are the
packages part of the DOM.

Most stuff in message is abstract, most class in field are interfaces, address and datetime
are abstract.

Problems to be fixed:
1) ParsedField interface has "isValid" and "getParseException": from the DOM perspective a
field should always be valid, shouldn't it? Shouldn't we throw exception during parsing instead
of building the dom node with  "isValid"/"getParseException" methods? Can you provide an use
case where an exception/monitor during parsing is not enough and we need to carry the "invalidity"
to the DOM?
2) Dependency on "MimeException": once we fixed #1 then we shouldn't have anymore the need
to depend on MimeException but maybe we'll need a new exception for DOM related operations,
DOM should not have any other dependency in mime4j, so we should probably introduce a DOMException
(or something similar)

Improvements:
- Introduce a basic interface for the "Node" and make the whole DOM a traversable tree: this
will give a lot of future options, like using XPath expressions to select mime nodes (needs
more thinking but could be very interesting: "//image[@type=png]" would select all parts with
a content type (image/png) at any depth level...
- Add manipulation methods: once we get an instance of the "root" Message we should be able
to add header, content, subparts and anything else only accessing the root object and the
DOM interfaces (the same as for an xml Document.. once you have it you don't need a DocumentBuilder
anymore).

Opinions?

> DOM (message) classes should not be implementation specific. Move implementation to a
different package (message.impl)
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: MIME4J-156
>                 URL: https://issues.apache.org/jira/browse/MIME4J-156
>             Project: JAMES Mime4j
>          Issue Type: Improvement
>    Affects Versions: 0.6
>            Reporter: Stefano Bagnara
>            Assignee: Stefano Bagnara
>             Fix For: 0.8
>
>         Attachments: graph-mime4j-package.png
>
>
> Let's start "splitting" message between generic interfaces/abstract classes and specific
implementations based on mime4j modules (parser).
> Abstract classes vs Interface is a tricky issue wrt api. I think the important thing
now is to separate implementation details from design/api.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message