Bundle Event Receiver (Pass Parsed Packet to Consumer Without Implicitly Unpacking Bundles)

[orchetect]

From @dsmurfin:

In our case it's ideal to be able to parse bundles directly rather than rely on OSCKit doing this for us. Sometimes knowing the structure of bundles is beneficial (crazy implementations), and also I have concerns about the overhead of dispatching so many individual messages for later execution.

I have already got a working branch which switches timeTagMode out for bundleMode containing 2 cases: .forward and .unwrap(timeTagMode: TimeTagMode). I can add this in a backwards compatible way with API deprecations.

[orchetect]

it's ideal to be able to parse bundles directly

I agree here - originally OSCKit delivered packets parsed as-is with bundles intact, but somewhere along the way to simplify things for the consumer we implicitly unpacked bundles prior to delivering received events to the consumer. It should have remained as-is with bundles in tact.

Currently the receive handler closures pass in OSCMessage. This could be changed to OSCPacket which is an enum with message and bundle cases.

oscServer = OSCUDPServer(port: 8000) { [weak self] packet, timeTag, host, port in
    switch packet {
    case let .bundle(bundle): // ...
    case let .message(message): // ...
    }
}

There are numerous receiver closure signatures in the module, so they would all need to be updated to be consistent.

The functionality of easily unwrapping bundles is available as a method on OSCPacket if consumers wish to invoke the convenience and do not have a need to parse out bundles.

oscServer = OSCUDPServer(port: 8000) { [weak self] packet, timeTag, host, port in
    let messages = packet.messages // recursively unwraps bundles, only returning `OSCMessage`s
    for message in messages { /* ... */ }
}

[orchetect]

I have concerns about the overhead of dispatching so many individual messages for later execution.
I have already got a working branch which switches timeTagMode out for bundleMode

I can see what you mean. If we refactor the receiver closures to deliver us an OSCPacket, then it raises the question of how we handle timetag scheduling internally.

Would it potentially imply that we have two different receiver closure signatures depending on what bundleMode is selected? It doesn't make sense to schedule an OSCPacket, but it would make sense to schedule OSCMessages that would otherwise be implicitly unwrapped.