hoijui / JavaOSC

OSC content format/"protocol" library for JVM languages

Home Page:http://www.illposed.com/software/javaosc.html

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Lower-level API for handling packets

daveyarwood opened this issue · comments

This is related to #19 in that I think it would solve my use case in wanting to handle the event scheduling myself, in a more general way.

After digging into the JavaOSC source code a bit further, I realized that the thing I want to be able to do is to go lower-level than the library currently allows.

My understanding of how to use JavaOSC on the server side is that you create an instance of OSCPortIn and add some listeners that implement the OSCListener interface, each of which handles messages for a particular address pattern. When a bundle is received, the individual messages are dispatched one-by-one to the relevant listeners for each message.

There is currently no publicly exposed way to listen for packets and handle them arbitrarily. The way I intend to use OSC is for clients to send either bundles or individual messages, and the semantics will be different depending on whether the client send a message (with no timestamp) or a bundle (a timestamped sequence of messages). I think what I have in mind fits well with the description of messages vs. bundles in the OSC 1.0 spec.

The immediate problem I'm having is that I can't implement a listener that can differentiate between messages and bundles. I can only provide a listener that works on the level of messages.

I think what would be ideal is if JavaOSC offered a lower-level API for handling packets (which could be either bundles or messages). Basically, I want to be able to replace this call to dispatchPacket in OSCPortIn.run with an abstract "packet listener" that reads packets and handles them in some arbitrary way determined by the library user. If no packet listener is provided, we could default to what it's doing currently. The idea is that you could continue to use the current, higher-level API and add message listeners, or you could opt to go lower-level and provide your own packet listener.

@hoijui What do you think? If you're on board with this idea, I'm happy to write a small PR to add this lower level API.

So basically:

// new interface
interface OSCPacketListener {
    void packetReceived(OSCPacketReceivedEvent event);
}

class OSCPacketDispatcher implements OSCPacketListener { ... }

class OSCPortIn {

    OSCPortIn(boolean defaultListener = true) {
        if (defaultListener) {
            addOSCPacketListener(new OSCPacketDispatcher());
        }
    }

    void addOSCPacketListener(...
    void removeOSCPacketListener(...
}

...not with this code of course, but as a rough sketch.
what do you think?

I am very tired right now, but sounds like a good idea in principle!
If you want to do it, best do it on top of the develop branch of course.

That looks about like what I have in mind!

I'll take a stab at this soon when I have a bit of free time.

done in branch develop as of now. thanks for the contributions dave!

@daveyarwood
are you fine with the current develop branch?
I am asking you because I think you are actively usign the library, while I am not.
If you deem it fine, I would attempt a release.

I'd love to see a release soon -- happy to see this moving along on the develop branch!

I'll give the develop branch a try soon (probably today) and let you know how it's working for me. I have a project that is using JavaOSC, so I have a good way to test it.

I just tried the develop branch and it's working great! 👍

thanks dave! :-)
I just added one more commit (plus a comment fixing one):
946434a

hope it is sitll fine for you. I plan to do the release tomorrow (tuesday).

@hoijui Those commits look good to me 👍

thanks dave! :-)
... I think I released it about 1h ago, but it should take some hours till it is visible everywhere.

Cool, thanks!