-
Notifications
You must be signed in to change notification settings - Fork 13
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
Support for multiple endpoints #5
Comments
Cool idea! I like it! Would this be a breaking change to the configuration? I do have to refactor this module because the Caddy module API will change or has already changed. Then I can implement it. |
Since we don't like nesting in the Caddyfile, typically the way to do this is to use the mailout directive multiple times, each one specifying a "rule" or a "config" of sorts. It may produce some duplicate lines but I think in general we prefer the simplicity. Now, you're of course welcome to do nesting but the parser (caddyfile.Dispenser) doesn't really support that first-class, it would need to be upgraded to do so. We hacked some support for nested blocks into log and errors to configure log rolling (just to see what it would be like), but I don't really like the complexity... |
Ok, so it's better follow caddy style. @SchumacherFM could multiple endpoints be made with multiple directives? Add a little of duplication, but, in the end, gonna work the same way. |
Thank you for the input @mholt very worth! I didn't know that nesting wasn't possible and also I do not want to spend too much time on implementing nesting. Multiple directies/endpoints would AFAIK easy to implement. |
This is what I tried before realizing it supports only one endpoint.
|
It's a total refactoring of the module ... might take some time. |
Don't stress yourself. One can already run multiple instances. Not perfect but manageable. If it can be done in the long term, it would make mailout match the other plugin behaviours more closely. |
There is any problem having multiple endpoints?
/contact/y
/contact/x
/contact/z
Maybe the DSL could contemplate, something like this:
The text was updated successfully, but these errors were encountered: