Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Version 0.3.3 of the IRC module already supports sending actions, so this function merely forwards the command to it.
As the action property stays undefined for standard messages, and the action property is also undefined with other adapters, this allows you to write hubot scripts that work with general adapters but can also receive and process IRC actions with the IRC adapter.
Version 0.3.3 of the IRC module (the one this module currently uses) doesn't emit an event for actions, but version 0.3.4 (the latest version) does. What I've done is write my own action detection code (a one line regex) inside the standard 'message' listener, but if the dependency is bumped up to 0.3.4 then the code needs to be changed by adding a new listener to the 'action' event instead.
If you do want to bump up the required version of the IRC module to 0.3.4, let me know and I'll commit the required changes. If you want to stay with 0.3.3 then these changes work fine.
Correct me if I'm wrong, but this functionality is not implemented by any other adapters (campfire or hipchat for example) and would only be useful specifically for IRC.
I can see the benefit of the IRC bot having extra functionality that other adapters don't have, but it limits the usefulness of scripts that would rely on this functionality and break if not properly safe checking for other adapters.
Just looking at some other adapters and can't really make a good judgment on what the precedent is for adding methods to the adapter for your service. I notice the campfire bot has a
On second thought, I think we should expose our custom irc functionality on the adapter. Scripts can always check for the existince via a
Plus, it means that our adapter would enable cooler scripts.
I like the idea of updating to the latest irc module as well. Can you update your pull request with those changes? Including bumping irc dependency in the
Well, Hubot will only ever implement common chat functionality so that it provides a bridge between chat protocols and user scripts. Even the notion of rooms/channels is largely ignored by Hubot. Actions, notices, topic changes, kicks, bans and other things just aren't universal enough.
Exposing IRC specific functionality is a two way thing. A user script would need to both send and receive these "special" messages in a way that doesn't break for other adapters.
You've mentioned in your last comment how a user script can call methods on an adapter using checks such as
For receiving specific messages like notices and actions, the only reasonable way to do it is to attach appropriate properties to the Message object like I've done here for actions. That way, user scripts can check the incoming messages by doing
This is a reasonable way to handle things. If, for example, hubot-irc was to receive quit messages, it could send them to user scripts by adding the message to a "text" property on the LeaveMessage object. Scripts that listen to user exiting can then choose to do
Of course, none of this is ideal because of the limitations with Hubot itself. In an ideal world Hubot would have an expanded Adapter class and Message class hierarchy to provide functions for all these things. Custom adapters like this one (and the default Campfire one) would implement the functions that they can handle and either ignore the rest or make intelligent substitutions (for example, an action or notice to a standard message).