Closed elazar closed 8 years ago
:+1:
Also been thinking, it should accept the sender and channel as well, that way we can ignore travis and github but keep handing on github and travis URL's not from them
True! Sending the original event object along with the extracted URL would offer all of the above options. :)
Just more work, but worth it :)
Been thinking about this some more and I'm currently researching using https://github.com/phergie/phergie-irc-plugin-react-eventfilter#userfilter to achieve this
Only thing I don't like about that idea is the dependency it introduces. Adding it would have to be handled carefully with respect to BC. Otherwise, I agree it's a good approach. :smile:
Judging by the diff between 1.0 and 2.0 I doubt that is going to be an API problem with the the current, lowest, highest setup we can test against mutiple versions when we target ^1.0||^2.0
:smile:
@elazar here is a think though, https://github.com/phergie/phergie-irc-plugin-react-eventfilter/compare/1.0.0...2.0.0#diff-8442cbb1e96da0737be107e4002519deL27 Right now I'm only letting messages pass if the result is true. But readying that diff it might be better if I just pass everything !== false
. What is your 2cents on this?
@WyriHaximus I think that makes sense. See also: the related section of the README.
PR is up #14
When third-party bots co-exist in the same channel as Phergie, the URL plugin can contribute to the noise-to-signal ratio.
It would be nice if it was possible to ignore some URLs based on specific components (e.g. hostname). This could be done by implementing a
FilterInterface
with a single method that accepts a URL and returns a boolean value indicating whether that URL should be handled or not. To maintain BC, a default that returnstrue
for all URLs could be implemented. This would allow for maximum flexibility and customization by the end-user.