1. Liam Staskawicz
  2. gosc
  3. Pull requests

Pull requests

#1 Declined
Repository
kellydunn
Branch
osc-server
Repository
liamstask
Branch
master

Simple Server implementation

Author
  1. Kelly Dunn
Reviewers
Description

These series of commits introduce an OSC server implementation.

Comments (3)

  1. Liam Staskawicz repo owner

    Heyo!

    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