Skip to content
New issue

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

Add buffered e-mail helpers #79

Open
emersion opened this issue Apr 6, 2020 · 3 comments · May be fixed by #115
Open

Add buffered e-mail helpers #79

emersion opened this issue Apr 6, 2020 · 3 comments · May be fixed by #115

Comments

@emersion
Copy link
Owner

emersion commented Apr 6, 2020

Not sure this is a good idea yet. Would need to have more use-cases in mind.

Some users of the library may want not to use a streaming API, for instance because they need to perform operations with multiple passes. We could expose APIs that let users process messages by loading them completely in memory, like almost all (or all?) other e-mail libraries do.

Of course this comes with the downside that whole messages (with their attachments) are loaded in memory.

@foxcpp
Copy link
Collaborator

foxcpp commented Apr 6, 2020

Keeping parsed MIME tree in memory along with contents can improve performance considerably if multiple passes are needed at the cost of memory usage. As compared to rerunning parsing function on each pass.

@emersion
Copy link
Owner Author

emersion commented Jul 8, 2020

  • Should this be tailored for emails, or for MIME messages in general?
  • Should we ensure reading a message and writing it back will yield a byte-identical result? (I think so)
  • Should we allow arbitrary message mutations? If so, how should the API for those look like?

@foxcpp
Copy link
Collaborator

foxcpp commented Jul 8, 2020

  • I believe it would be a fair decision to tailor it for email use since that's where go-message is used the most.
  • There are subtle format pitfalls that may prevent us from doing so. Hard to tell what we are doing without concrete use cases in mind.
  • I am not going to try designing an API without an idea what it could be used for.

@emersion emersion linked a pull request May 6, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants