We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
We started by just adding the attachments as base64 encoded data in the right place of the email. It was a simple implementation.
With the pull-request #137, we discovered the way we encode attachment can be related to the content-type of the attachment.
When we added the fixes, we had to split logic in two different places:
If we start to split the logic in different places I'm a bit afraid the maintenance will become harder when we add more kind of attachments.
We need to think / draft how to refactor this part of the library to make it easier to add support for new kind of attachments.
The text was updated successfully, but these errors were encountered:
No branches or pull requests
We started by just adding the attachments as base64 encoded data in the right place of the email. It was a simple implementation.
With the pull-request #137, we discovered the way we encode attachment can be related to the content-type of the attachment.
When we added the fixes, we had to split logic in two different places:
If we start to split the logic in different places I'm a bit afraid the maintenance will become harder when we add more kind of attachments.
We need to think / draft how to refactor this part of the library to make it easier to add support for new kind of attachments.
The text was updated successfully, but these errors were encountered: