You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by "Stefano Bagnara (JIRA)" <mi...@james.apache.org> on 2009/12/31 15:59:29 UTC
[jira] Created: (MIME4J-156) DOM (message) classes should not be
implementation specific. Move implementation to a different package
(message.impl)
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
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.
[jira] Commented: (MIME4J-156) DOM (message) classes should not be
implementation specific. Move implementation to a different package
(message.impl)
Posted by "Stefano Bagnara (JIRA)" <mi...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795772#action_12795772 ]
Stefano Bagnara commented on MIME4J-156:
----------------------------------------
OK, I just completed DOM extraction and dependency clean up for the dom.
> 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
>
>
> 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.
[jira] Updated: (MIME4J-156) DOM (message) classes should not be
implementation specific. Move implementation to a different package
(message.impl)
Posted by "Stefano Bagnara (JIRA)" <mi...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara updated MIME4J-156:
-----------------------------------
Attachment: graph-mime4j-package.png
This is the current dependency graph (simplified by grouping the field.*.parser packages).
Black lines are transitive reduced dependencies (grey lines full package dependencies).
As you can see DOM does not have any dependency.
Further improvements to the dependency tree belongs to another issue, so I hope to close this one soon.
> 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.
[jira] Resolved: (MIME4J-156) DOM (message) classes should not be
implementation specific. Move implementation to a different package
(message.impl)
Posted by "Stefano Bagnara (JIRA)" <mi...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefano Bagnara resolved MIME4J-156.
------------------------------------
Resolution: Fixed
Merged from cycleclean branch. Created MIME4J-172, MIME4J-171, MIME4J-170, MIME4J-169 for the tasks/pending things discussed in the last comment.
> 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.7
>
> 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.
[jira] Commented: (MIME4J-156) DOM (message) classes should not be
implementation specific. Move implementation to a different package
(message.impl)
Posted by "Stefano Bagnara (JIRA)" <mi...@james.apache.org>.
[ 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.
[jira] Commented: (MIME4J-156) DOM (message) classes should not be
implementation specific. Move implementation to a different package
(message.impl)
Posted by "Stefano Bagnara (JIRA)" <mi...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MIME4J-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795631#action_12795631 ]
Stefano Bagnara commented on MIME4J-156:
----------------------------------------
Current status:
field is clean
field.impl contains the field parser implementations and field implementations.
message is clean
message.impl contains classes depending on field.impl and parser
Todo:
field.address contains both api and impl code (static methods).. needs the same treatment done to field.
parser should be split in 2, moving code with no dependencies into a subpackage (or viceversa, creating an "impl" there, too). descriptor package should be merged to parser (and then splitted between api/impl).
util/codec/io needs some review. e.g: io is only used in parser, maybe it should be moved to parser.io to make it more clear in future.
> 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
>
>
> 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.