search

mendicant-original / newman

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

default skip response off (for multi-app scenarios) #35

Closed ericgj closed 12 years ago

ericgj commented 12 years ago

Currently, when you skip_response, it disables delivery of the response not only for the current app but for any downstream apps that might match the same email.

I thought it might be more intuitive to have skip_response apply only to the current app. See what you think.

(I also updated the integration tests for skip_response to work with the current Server interface. Let me know what you think of that approach and I can update the other integration test files.

practicingruby commented 12 years ago

I think I dislike this approach for the same reason I dislike having some sort of "halt any response-sending applications"... we should not force horizontal changes through a vertical pipeline... instead we should allow for horizontal request mapping. The vertical path should represent a sequential workflow, not a case statement with fall-through behavior.

request logging -> application code -> response logging is an example a sequential workflow.

app_handling_topic_a -> app_handling_topic_b -> app_handling_topic_c is a case statement with fallthrough behavior.

Instead we'd want to map those, so we have...

          ________app_a
         /
        /
router -----------app_b
        \
         \________app_c

Hope that makes sense. Maybe application is a bad name which is leading you to go down this road of wanting to stack unrelated applications? Maybe they're actual RequestHandlers?

ericgj commented 12 years ago

Yeah, it occurred to me too just now that it's not the right approach given how the server loop works. For one thing, it not going to work right with things like the ResponseLogger.