Skip to content

Actions #45

wants to merge 2 commits into from

3 participants

botdev commented Oct 20, 2012

1) I've added a function to perform IRC actions (usually a /me command in user clients). To use it in a script you can do:

robot.adapter.action user, "self destructs."

Version 0.3.3 of the IRC module already supports sending actions, so this function merely forwards the command to it.

2) I've added action receiving too. In order to do this, the created TextMessage object is given an action property (set to true) when the message is an action. This means that in a script you can do:

if message.action
  robot.adapter.action message.user, "has received your action."

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.

jgable commented Oct 25, 2012

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 topic method.

jgable commented Oct 25, 2012

On second thought, I think we should expose our custom irc functionality on the adapter. Scripts can always check for the existince via a robot.adapter.action? check.

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 package.json?

botdev commented Oct 25, 2012

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 robot.adapter.notice?, robot.adapter.kick? and robot.adapter.action?. This is indeed the best way to do it as things stand.

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 msg.message.action?. For scripts that don't care about receiving actions, nothing needs to be changed.

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 msg.message.text? to detect the presence of a quit message, while all standard scripts continue to work without it.

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).

jgable commented Nov 6, 2012

I've upgraded to the 0.3.4 version of the irc module in the latest npm version. If you want to adapt your pull request for this, that'd be great. Otherwise, I'll close it in lieu of another one.


Ping @BotDev

jgable commented Jan 22, 2013

Going to close for the time being as there is no one to take this up.

@jgable jgable closed this Jan 22, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.