go-message
go-message copied to clipboard
Add buffered e-mail helpers
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.
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.
- 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?
- 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.