vimalloc/weechat-alert

Weechat relay to make sound alerts when used behind tmux

weechat-alert's Issues

Various refactor ideas

MessageData to MessageBody
DataType to HDataType
etc

Ping timeouts

Ping/pong every so often to make sure the connection is still alive

Panic when sending message to a new buffer

Can reproduce with "/query <non_opened_buffer> Hey"

thread '<main>' panicked at 'arithmetic operation overflowed', src/parse.rs:239
AL lib: (EE) alc_cleanup: 1 device not closed
error: Process didn't exit successfully: `target/debug/weechat_alert` (exit code: 101)

Add HashTable to DataType

Forgot to implement this on the first go around

Turn into a library

Make the relay portion of this a library, where you can register callback handlers for incoming data. This is totally unnecessary for the app I'm building, but I think it would have a few benefits for learning rust, namely

1. How to build and use a library.
2. Dealing with threading so users can send messages independently of recving them

If let

Random comment on reddit, it looks like "if let" may help clean up some of the match/panic code I have everywhere. Look at this

Send and Recv support

We need to be able to send and receive data on the socket concurrently (or similar to that with a non-blocking or asynchronous approach). This is so that we can send pings every so often to check the state of the socket, and so that other people using this as a library could send commands without having to wait for a recv call to happen first (ex, sending a message to a buffer).

Originally, I was planning to simply use try_clone on the socket, and setup 1 thread for receiving and 1 thread for sending. However, apparently this doesn't working ok SSL sockets (see sfackler/rust-openssl#338 and http://stackoverflow.com/questions/14467630). With that out of the question, I think using a non-blocking socket to do both the sends and receives is probably the best way to go.

Use Ear to play sounds on incoming messages

Move away from one giant file

Remove all calls to panic!

Everything that can go wrong should return a weechat error instead of panicing.

After parsing message, insure all bytes have been read.

String vs str

I have a feeling I'm doing a lot of pass by values and copying strings around using String::from() all over the place, that could be better handled by passing string references around. Need to look into this more

Having basically ever struct pub smells

I think I should re-arange this stuff. My initial thought is have a generic Message class. It implements message header, message body, etc. It also reads from a socket to build these things. Maybe. But that also sounds smelly. Hrm

SSL support