1. Liam Staskawicz
  2. gosc
  3. Pull requests

Pull requests

#1 Declined

Simple Server implementation

  1. Kelly Dunn

These series of commits introduce an OSC server implementation.

Comments (3)

  1. Liam Staskawicz repo owner


    Cool beans. I actually have a bunch of requests before merging this :D

    • run go fmt to make sure formatting is consistent
    • please defer moving files into other directories for a separate pull request, since that makes it harder to see which changes are part of your implementation and which are just a result of the move
    • the server should dispatch messages based on the PatternMatch functionality I just started adding (see pattern.go), rather than straight string compare
    • the server should be structured a bit more like the net/http package (http://golang.org/pkg/net/http/):
      • define something similar to http.HandlerFunc for all receivers of osc messages
      • i think we should deliver messages to receivers directly when we receive them, rather than through a channel - people can coalesce those through a channel externally if they need to
      • create something similar to http.Handler to register receivers on (this is kinda similar to your Router)
      • create something similar to http.DefaultServeMux so that people can register receivers without creating their own Handler in the common case
      • Server should accept a Handler in its Serve() routine - if it's nil, use DefaultServeMux (or whatever we call it)
    • can we get away without a NewServer method? would be nice to just have a composite literal, then something like http.ListenAndServe()
    • Serve() needs to return an error
    • Serve() will want to wait for data to arrive before calling ReadFrom() - does this work currently, if there's no data already available on the connection?
    • we should allow for other transports (namely TCP) - maybe just a naming convention would be sufficient (OscUdpServer, or similar)

    that's all I can think of for now :D

  2. Kelly Dunn author

    Sounds good!

    re: "i think we should deliver messages to receivers directly when we receive them, rather than through a channel ":

    Are we concerned about running the callbacks in the same goroutine as the server? A fellow golang enthusiast mentioned that that might be somewhat problematic, which is why I opted for a more channel-oriented approach.

    I can change it for now, just wasn't sure if there were specific pros/cons for either design decision.

    Also apologies on the formatting, forgot that go prefers tabs over spaces :P

    1. Liam Staskawicz repo owner

      The user doesn't actually need to run the server in a goroutine if they don't want to - if they don't, then handling results on a channel is probably overkill. if they do decide to run it in a goroutine, then I think it's clearest if they decide how to deal with it in their receivers.

      re: formatting, no worries - fortunately go fmt takes care of tabs/spaces and all other sorts of formatting details