mendicant-original / newman Goto Github PK

The logic should be application-specific, but the matcher(s) could probably be generic. I didn't see that the Mail gem has any facilities for this, but I might have missed it.

Take a look at this gist:
https://gist.github.com/1732428

I've thought about two solutions to accept multiple applications for one server:

• make the server coupled to appilcation. so it's one application for one server and make a "Master server" to handle the servers.
• leave the server (just making the "right" fix) but make the mailer local to application (preventing other application to access a mail from one).

I'll do some work on this later, but i wanted to share with you this concern, maybe you guys think on other solutions.

I'd like to do a Newman application that makes use of the old rmu/scheduler.

Basically the way I see it working as a first draft, is

1. people send in their available times during the week in a standard (but flexible) format, to a c+{activity}.schedule.add address;
2. at any point anyone can query the most available timeslots by sending an email to c+{activity}.schedule.list address

Possibly we would want to then integrate this into a mailing list app (so commands would be limited to list participants), but for the first draft it would be 'open'.

(Also maybe later we could extend it to put in vertiginous' nice graphical chart in the email, though I'm not really up on how possible it is to run javascript in email parts...)

I'd want to consult with @bglusman about his GetTogether app, which possibly has some overlap, or maybe should be integrated together at some point, at least in the sense of having a consistent user interface.

What do you think?

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.

A lot of complicated issues arise from having only a single linear path to mount applications in. We need either a horizontal mapping at the top level, or a composite application router that could be dropped anywhere within the linear chain.

Top level horizontal routing:

request -> router ---> app_a---> response (if matched)
                  |
                  ---> app_b---> response (if matched)
                  |
                  ---> app_c---> response (if matched)

Composable router application. This seems more promising and logically easier to think through, but retains the "one request, at most one response" limitation. Still have not figured out whether that is going to really harm Newman's usability for scenarios we're interested in.

request --> (pre apps) -> router_app--> component_app_a----> (post apps) -> response
                                      |                    |
                                      > component_app_b----^
                                      |                    |
                                      > component_app_c----^

Right now, if the request email coming in to your application isn't correct in some application-specific way, can't be parsed etc., your callback might look like

if valid?(request)
  ... 
  respond( ... )
else
  respond usage_response
end

Which is fine for simple cases, but if you have several different error conditions that each call for different behavior/responses, the code starts getting ugly with nested if's. One thing that might be helpful would be a way of exiting the callback early. You could use next -

unless valid_subject?(request)
  respond error_invalid_subject
  next
end

unless valid_body?(request)
  respond error_invalid_body
  next
end

... continue processing after validation passes

or to DRY it up, -

validate({:valid_body? => error_invalid_body,
          :valid_subject? => error_invalid_subject}) or next

... continue

But somehow that still isn't satisfying. Not suggesting rails-style controller validations, but maybe something Newman::Controller could help with that I'm not thinking of.

I want to add a newman executable that takes a file similar to a rackup file and allows for something like

$ newman some_runner_file.rb --tick
$ newman some_runner_file.rb --loop --config path/to/config

Need to think through what the runner file syntax will look like, but it should be fairly minimal while exposing a server object (or similar) for manual configuration

This information could be presented as a bulleted list at the top of settings.rb, or in newman.rb, whichever ends up being better. I am already mentioning them where they are used, but it'd be nice to have a unified resource for how to construct a configuration file from scratch.

This should actually probably go in the tracker for MailWhale, but I'm opening a ticket here to make us think through what should be done in Newman itself to make this easier.

See #31. Basically, default_logger caches the logger object as soon as Server object is initialized, preventing a change made to the debug_mode settings from taking effect if it is made after the object was created but before a tick or run call is made. I could easily move the logger caching code into tick (and it'd be a no-op on subsequent ticks), but that feels nasty. @brentvatne, @ericgj, thoughts?

Include basic usage / setup instructions, a license, and how to get in contact.

See discussion on the more general ticket #5.

Currently a key called :match_data is being added to each callback each time call is run, but this is leaving state lingering around after a request is completed that is no longer relevant. It'd be possible to make this stateless.

Hi there,

We are looking at this newman gem and I think it can be useful for us. We are using Rails 3.2.2 which depends on the mail gem version 2.4.x; however, the gemspec of newman currently set to use mail 2.3.x, so bundler would have problem resolving the correct version for mail gem.

Is there any reason sticking to 2.3.x in newman? Can it use mail 2.4.x?

Thanks,
Alex

See conversation between me and @ericgj raised on this issue

If there are network errors either receiving or sending, it kills the server. Perhaps this is the desired behavior, and in production you just monitor the process and restart it if this happens. But in any case I'd think you'd at least want to log the error.

Right now the server model is single-request, single-response. It's easy to think of other use-cases that don't fit this model: for instance

1. broadcast 'mail-merge' emails,
2. email that just sends a command and doesn't need any response,
3. response emails get queued up or combined for later delivery, e.g. 'digest' emails might work this way

None of these seem high priority for us, in fact I'd be happy never to build a platform for spam (#1) :)

But something to consider at some point whether the app should have more control over the response flow, rather than the server.