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

Configuration profiles #27

Open
practicingruby opened this issue Feb 15, 2012 · 2 comments
Open

Configuration profiles #27

practicingruby opened this issue Feb 15, 2012 · 2 comments
Labels

Comments

@practicingruby
Copy link
Contributor

Something like this, to simplify email configurations for common providers. This will rest on top of our smtp / imap objects rather than replace them.

mail_provider :gmail do |provider|
  provider.username = "..."
  provider.password = "..."

  provider.overrides do
    smtp.something = ... # a post hook, only used for special casing
  end
end

Ideally, there will be a nice internal API for defining new provider types, so that third party extensions can add their own, and so that it is easy for users to contribute these profiles to Newman itself.

@samnang
Copy link
Member

samnang commented Feb 27, 2012

How about something like this in config/environment:

mail_provider :gmail do
  username ""
  password ""

  smtp starttls_enabled: true, port: 587   # only used for special casing
  imap starttls_enabled: true, port: 993   # they should be there in provider class by default
end

set :simplelist_db, "db/lists/simple_mailing_list.store"
set :librelist_db, "db/lists/libre.store"
set :ping_email, "<<USERNAME>>+ping@gmail.com"
set :live_test_delay, 5

set :domain, "gmail.com"
set :templates_dir, "views"
set :default_sender, "<<USERNAME>>@gmail.com"
set :polling_interval, 10

I don't know what's the different between service and application settings, shouldn't we just call settings and set those setting values by calling set method?

@practicingruby
Copy link
Contributor Author

wherever possible, I'd prefer to avoid switching context via instance_eval, so that means I would want to yield a provider object rather than instance_evaling code against one in mail_provider. The difference between service and application is that service exists to tweak configuration settings Newman provides and application exists to provide the user with a way to add their own configuration data to the system which is NOT meant to be used by newman. These two namespaces are significant... Newman will eventually add validations for its own settings and then service will no longer be an openstruct.

set is nice because it looks familiar to sinatra developers, but is a bit too limited for what we're trying to do here. I actually am very happy with the segmented Lua style configs we have now, I just want to make setting email providers a bit easier because it is a common operation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants