My list is less exciting than most, but here goes.
(1) A 'get ENet version' function. Linux distributions tend to lag on
versioning, and this would allow precompiled binaries to take advantage
of new features if a new version is detected, without breaking
compatibility (newest Ubuntu is still on 1.3.3 for instance).
(2) Consistent library naming. libenet.so symlinks tend to be in
developer packages, so that can't be used directly, and I noticed on
Ubuntu it's libenet.so.1 while the Git repo builds libenet.so.2. This
could be a problem for distributing precompiled binaries.
(3) C accessors for parts of structures that are meant to be accessed,
so that ENet structures can be treated as opaque. Seems to be a pattern,
all of these three have been related to binary compatibility. :)
(4) EINTR. When we discussed this I was coming from the angle of using
Mono, which provides no useful access to signals, so I didn't understand
your meaning. Pondering other platforms where signals could be useful I
see your point. That said, lack of EINTR handling does need some
resolution - at the very least, some way to know ENet is returning a
failure case that should just retried.
Biggest problem if one goes that route is enet_host_service being a
timeout not a time. Maybe if the timeout parameter in a
enet_host_service2 were a pointer type and was decremented by elapsed
time? That'd do the trick and be compatible with the way you were
talking about..
(5) ENetBuffer's structure is in reversed order Unix vs. Windows. Opaque
structures would solve this, but might be overkill for such a simple
one. Unless there is a technical reason for this difference, it'd be
nice if it could be unified.
(6) Could ENetSocket be made always of uintptr_t size? This difference
means I cannot practically expose the low level socket APIs in a
cross-platform manner.
(6) Is thread-safe reference count increment/decrement architecturally
practical? On Mono one cannot control the thread for cleanup. The
practical effect is that ENet structures on Mono have to be disposed of
manually and can't be made to work with automatic garbage collection.
This is really not critical, but *if* it's not overly complicated ENet
could be made downright pleasant to work with from C#.
(7) The 'simulate lag/packet loss' that I see many posts of would be
nice. For simulating lag, perhaps you could use the outgoing queue's
retry timing but just also apply it before the first packet is sent?
If I can be of help on any of these please let me know.
Have a good day
James
On 4/30/2013 5:43 AM, Lee Salzman wrote:
So, I'm just thinking in the back of my mind what sort of things would
be desired in a hypothetical version 2.0 of ENet that broke API
compatibility and so could do things that would otherwise not be
possible in a 1.x release.
That doesn't mean that a 2.0 is in the near future, but I'd like to
get a dialogue going about it.
Aside from IPv6 support, are there any other big things people would
want that are none-the-less realistic and not overly complicated?
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
