mendicant-original / newman

Newman: a microframework for building email-based applications.
116 stars 11 forks source link

Configuration profiles #27

Open practicingruby opened 12 years ago

practicingruby commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

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.