Support Conform Style Configuration about swoosh HOT 7 CLOSED

Thanks for your input @xadhoom !

from swoosh.

Hi @geofflane, sorry for the slow reply on this one.

I'm not really a fan of we deal with configuration at the moment, I'm going to rethink this in the next few days and I'll make sure we support conform.

If you have any ideas, please feel free to share.

from swoosh.

@stevedomin I don't have a lot of ideas necessarily. I'm not a huge fan of Mix.Config because it generates a static config at compile time and each individual library has to support things like :system if they want to have dynamic runtime properties. And each library has to be written so that is supports a model like Conform. That's a significant limitation of the Mix.Config design IMHO. I think the best I can come up with is to ensure that compile-time macros are not the thing that reads the configuration (no storing values in module attributes in the macto). Rather the configuration needs to be read when the application is running which allows a tool like Conform to interject itself and set the configuration up properly.

The only other idea I have, and I haven't tried this anywhere, is that it might be best if libraries with configuration had their own Agent (or GenServer or something) that was responsible for reading the configuration it needed when it started and then the code that needed the config could just ask for it from the Agent. Agents make sense to me because the library depends on global state already through a module attribute, and Agent is just an abstraction around state.

from swoosh.

I'm also interested in this topic, right now the only way is to pass env vars on startup which is far from being optimal.

from swoosh.

@xadhoom what do you think is the optimal way?

from swoosh.

Well,

I see basically 2 use cases (in addition to current "static" mix way):

1. release mode, where the setup is read from a sys.config (which is generated by tools like conform)

2. dynamic mode, where I want to choose the adapter/config each time I send an email (think about it as a "multihomed" setup where each user wants to deliver his emails in a different way

The first one can may solved with a wrapping module that basically calls Application.get_env without the burden of a separate process, this will be called by the macro-defined functions everytime without relying into a compiled in config. I don't think is more expensive than calling a process (but I have no data about that and it may be interesting to investigate on systems that do tons of deliveries)

The second one is almost there, since (if I'm not mistaken) swoosh already permits passing a config to the deliver fun, but does not allow passing an adapter. Basically we need a deliver/3 where also adapter is passed (or a deliver/2 where 2nd argument is a tuple {adapter, config}). Where to store that config is basically delegated to the user of the library.

At a first glance, both ways may be added to current code without breaking the compatibility.

jm2c

from swoosh.

obviously both modes are usable at same time, is just a matter of which deliver fun the user calls (so the env config will be used unless overridden by calling deliver/3)

from swoosh.