Skip to content
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

Open
rynorris opened this issue Apr 17, 2017 · 4 comments
Open

Interface rewrite #38

rynorris opened this issue Apr 17, 2017 · 4 comments
Assignees

Comments

@rynorris
Copy link
Collaborator

rynorris commented Apr 17, 2017

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.

@ghost
Copy link

ghost commented Jun 27, 2017

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

@StefanKopieczek
Copy link
Owner

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!

@ghost
Copy link

ghost commented Sep 6, 2017

no probs....

@ghost
Copy link

ghost commented Sep 6, 2017

BTW. Is there any client code to test the golang code with, so i can get a handle on using this ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants