gossip
gossip copied to clipboard
Interface rewrite
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:
// Create transport.
transport := transport.NewUDP(...)
// Create TM.
tm := &transaction.Manager{
Transport: transport,
Handler: myHandler,
}
// Blocks forever.
tm.ListenAndServeSIP()
Client API becomes blocking (greatly simplifying testing)
// Non-invite flow.
req := &base.Request{...}
resp, err := tm.Send(req)
// ... do stuff
// Invite flow.
req := &base.Request{...}
resp, err := tm.Send(req)
tm.Ack(resp)
Additionally propose renaming "base" package to "sip" so the main objects are called helpful things like sip.Request
, sip.Response
etc etc.
Why not use protobuf s and go-kit ? The protobuf describes the and API. Go kit provides many transports. This is very nature and flexible approach.
Channels are good the the UA / GUI is also built in golang, because the channels of course can be used by the GUI directly. I do this for desktop and mobile apps using golang and GL.
Go kit can work fine with channels. Or you can use a message bus and then put transports on top including go channels. .plenty of great examples of all the above on github.
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 ?