You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using a different encoding/decoding library than eiconv i need to make a fake module that implements the convert/3. if a dependency uses eiconv, it might lead co conflicts.
my suggestion is to have it being configurable, so gen_smtp uses the configured module, otherwise keep using eiconv.
for the sake of documenting it would be good to have a behaviour defining a contract for convert/3.
The text was updated successfully, but these errors were encountered:
That should be relatively easy to do. You could just add a new option key to mimemail's options tuple and thread it through to where it calls mimemail:convert/3
yep, i'm planning to work on this this weekend, just asking if the approach is approved. should i include the behavior? probably mimemail_encoder or something like that
I am not super concerned about the behaviour, if someone configures a module that doesn't work it can just crash, or you can use module:is_exported. Using a behaviour would introduce an annoying dependency, I think?
When using a different encoding/decoding library than
eiconv
i need to make a fake module that implements theconvert/3
. if a dependency uses eiconv, it might lead co conflicts.my suggestion is to have it being configurable, so
gen_smtp
uses the configured module, otherwise keep using eiconv.for the sake of documenting it would be good to have a behaviour defining a contract for
convert/3
.The text was updated successfully, but these errors were encountered: