-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interface rewrite #38
Comments
Why not use protobuf s and go-kit ? Channels are good the the UA / GUI is also built in golang, because the channels of course can be used by the GUI directly. Go kit can work fine with channels. Or you can use a message bus and then put transports on top including go channels. Would like to see a golang sip stack :) buzz me if I can help with links, etc |
Hey, thanks for the suggestion but I think protobufs are overkill for communication between goroutines in the same process, and don't solve the code hygiene problem Disco was flagging. I think his handler proposal is probably the right call - I just need to find time to write it! Cheers for the input though, I do appreciate you taking the time to share your thoughts! |
no probs.... |
BTW. Is there any client code to test the golang code with, so i can get a handle on using this ? |
Our interface is a bit weird at the moment, and uses channels and stuff to communicate with the user. I think exposing channels like this is a bad idea. If we expose a simpler interface, the user can decide to send the messages down channels themselves if they like.
I propose a handler based interface similar to
net/http
. Something like:Client API becomes blocking (greatly simplifying testing)
Additionally propose renaming "base" package to "sip" so the main objects are called helpful things like
sip.Request
,sip.Response
etc etc.The text was updated successfully, but these errors were encountered: