[
https://issues.apache.org/jira/browse/JAMES-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093509#comment-17093509
]
Benoit Tellier commented on JAMES-2997:
---------------------------------------
https://github.com/linagora/james-project/pull/3335 contributes strong typing
for Attachment content type
Discovered bug:
- TextExtractor doing comparison on the full field instead of mimeType
- Wrong charset management in text extractors
> hasAttachment SHOULD be metadata read level
> -------------------------------------------
>
> Key: JAMES-2997
> URL: https://issues.apache.org/jira/browse/JAMES-2997
> Project: James Server
> Issue Type: Improvement
> Reporter: René Cordier
> Priority: Major
> Fix For: 3.6.0
>
>
> The description is well detailed in this mail :
> https://www.mail-archive.com/server-dev@james.apache.org/msg63511.html
> We are working on JMAP, and EMail::hasAttachments metadata is listed as
> a fast property.
> However to retrieve it today, we need to do a full message read in order
> to load attachment (as JMAP hasAttachment do not take inlined
> attachments into account and mailbox property do).
> Also, while inspecting the code, MessageResult::getLoadedAttachments is
> never used with attachment bytes. This means that given an email with a
> 10 MB attachment, upon GetMessages call with full profile, we are going
> to read the full eml (10 MB) then load attachment bytes (10 MB) while
> the attachment could have not been loaded in the first place. In our
> little example we read 20MB while only 10 MB could have been necessary.
> This attachment over-reading results in both performance and cost issue
> on the object storage - what is the topic me, René and Duc are currently
> working on.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
