Details
Diff Detail
- Repository
- R162 Kube
- Branch
- dev/mimetreeinterface
- Lint
No Linters Available - Unit
No Unit Test Coverage
The current version does not compile! Please only look at interface.h
The basic idee:
- We have Parts as structual elements (Alternative (where you can select what you want), Single, Encapsulated & Encryption)
- Content represent a piece of a Part ( one part can return multiple contents)
- MailMime is a representation of the MimePart of the email, we need, because we need to ask if a content should be show, we have to need to ask for dispossition, if there is a name/filename set for the content
- We ask for "ContentParts" what we should show (return List of differnt parts)
- Ask for Attachments for what should been shown as Attachment
- Ask for EmbededMsgs to get a list of Embeded messages
Looks good.
For encrypted contents:
If I look for ContentParts and everything is already decrypted I suppose we don't have a problem. But if it isn't, what kind of ContentPart do I get to represent the decrypted messages, and how do I trigger decryption?
framework/domain/mimetreeparser/interface.h | ||
---|---|---|
90 | What is this used for? Is the identifier stable over different parsing runs? | |
202 | If availableContents is in Part, shouldn't content(const QByteArray&) also be there? |
framework/domain/mimetreeparser/interface.h | ||
---|---|---|
90 | yes it should be stable over the runs - It can be used for scrolling to the correct part, if a rerun is needed f.ex. |
The triggering of decryption I have not impleneted right now, because currently we decrypt by default everything. My thought is to go the StatusObject way. And trigger the decryption from parser ala parser.decrypt(encryptionpart) or decrypteverything ala parser.decrypt(). If we would use encryptionpart.decrypt, than the part must hold a reference to parser, so that the parser can trigger a update signal.