Show HN: Tenyks – The service-oriented IRC bot I've been working on(github.com)
github.com
Show HN: Tenyks – The service-oriented IRC bot I've been working on
https://github.com/kyleterry/tenyks
6 comments
I've always enjoyed ii. And anything from suckless for that matter. I was a heavy dwm user until I switched to xmonad.
This is pretty neat. I've taken a similar approach in writing an irc bot using evented PHP and phergie-irc-client-react using redis to pass JSONed messages back and forth between services. It's surprising more IRC bots aren't taking advantage of message queue type architecture instead of monolithic plugin based bots.
This is a pretty interesting approach...I assume your idea is that people will use this as just a "means to an end" for connecting some sensor service to IRC for notification purposes, or to respond back to the user(s). However, I do have one question: Why is there data duplication? Like, why do you have both `fullmsg` and `full_message`? Same with the incoming payload, you mean to tell me that I have to have both `"fromchannel":true,` AND `"from_channel":true,` in there? That seems a little silly.
One more thing, I noticed the README says "I'm also planning a 2.0 branch which will use ZeroMQ instead of Redis."...did you ever try just using Go's channels to make this work? It's kind-of like a built-in ZMQ...
One more thing, I noticed the README says "I'm also planning a 2.0 branch which will use ZeroMQ instead of Redis."...did you ever try just using Go's channels to make this work? It's kind-of like a built-in ZMQ...
Thanks! The data duplication is due to my laziness. I've been running tenyks for about a year now and I have written a large number of services for it in python. They expect "full_message", but I wanted to make the API more go-like in the core, so I decided to go the fullMsg route. I should have been more pragmatic about it and just stuck with full_message. I may just rip out fullmsg and fromchannel.
ZeroMQ isn't for internal goroutine communication. It's to provide pub/sub for external services written in any number of languages.
I hope this answers your questions.
ZeroMQ isn't for internal goroutine communication. It's to provide pub/sub for external services written in any number of languages.
I hope this answers your questions.
This is nice! I've tried something similar myself as a first project and I'm learning some neat things from your code. Thanks for sharing :)
In the Linux desktop world, Telepathy serves a similar role: it's a unified daemon that handles all account connectivity (XMPP, Irc, Sip, Jingle, Aim, MSN, &c), and other programs talk to Telepathy instead of making their own connections. Telepathy and Tenyks are both communications services.
D-Bus is used to talk to Telepathy, which fills the role ZeroMQ plays in Tenyks.
D-Bus is used to talk to Telepathy, which fills the role ZeroMQ plays in Tenyks.
This looks great! I tinkered with building a similar service-oriented bot, using ZeroMQ for communication (though not very robust as it would block for responses IIRC); http://demonastery.org/2012/07/building-a-decoupled-irc-bot-...
https://github.com/iibot-irc/core
Based on ii (a file-system-based IRC client from suckless) with cron for regular tasks, inotify for responding to things etc.
(Not actually intended for other people to use, although its been abstracted enough that at least one other person has.)