unstable API?

[robochase6000]

what do you mean when you say the API is unstable?

I've had a lot of luck with hxudp so far in some of my networking experiments (mostly localhost, a few remote tests), and I've started to build a nice, event-based layer on top of this. Just wondering if the instability is something i should worry about. i.e. changing function signatures isn't a big deal, but if there is something in the code that is fundamentally broken, it'd be cool to know about it before i sink too much time into this.

Thanks!

[andyli]

I'm glad to know the lib works for you! Initially when I wrote this lib, it is kind of a quick-and-dirty port of ofxNetwork, an addon of openFrameworks. I planned to modify the API such that it is more haxey, and probably simply follows sys.UdpSocket which is introduced in Haxe 3.2. But to be honest I haven't really used this lib myself for a long time, and it may be better for me to contribute directly to the udp support in haxe std lib, thus I lack motivation to work on hxudp at the moment.

[robochase6000]

cool, thanks for the update!

so is udp working in haxe 3.2? it looks like i'm still on 3.1, and i think last time i was looking at haxe's built in udp stuff, it looked like it was non-functional in the source code (like in the link you posted, the functions just return 0, constructor straight up throws an error lol). if it's not functional, is there a timeline or anything that you know of? Sorry if you're not the right person to ask, but it seems from what i've gathered searching for udp stuff on googly, you are :)

[andyli]

FYI, you may check your haxe version by haxe -version.

Some of the implementations of the classes in haxe std lib are separated into target packages. e.g. for sys.UdpSocket, the neko implementation is at neko/_std/sys/net/UdpSocket.hx depending on the not-yet-released neko version 2.1, and the cpp implementation has not yet been done yet (see HaxeFoundation/haxe#3951). So, sadly, it can hardly be considered as "functional".