3 ms·
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 fo
by tomphoolery 12y ago
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...
- vhost- 12y agoThanks! 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.