<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">My list is less exciting than most, but
here goes.<br>
<br>
(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).<br>
<br>
(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.<br>
<br>
(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. :)<br>
<br>
(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.<br>
<br>
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..<br>
<br>
(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.<br>
<br>
(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.<br>
<br>
(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#.<br>
<br>
(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?<br>
<br>
If I can be of help on any of these please let me know.<br>
<br>
Have a good day<br>
<br>
James<br>
<br>
On 4/30/2013 5:43 AM, Lee Salzman wrote:<br>
</div>
<blockquote
cite="mid:CAPk1TVHE5+jUTtT+zXvOcp=D1+pbxAEd47MV2ELjPW-35V=O1Q@mail.gmail.com"
type="cite">
<div dir="ltr">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.
<div>
<br>
</div>
<div style="">That doesn't mean that a 2.0 is in the near
future, but I'd like to get a dialogue going about it.</div>
<div style=""><br>
</div>
<div style="">Aside from IPv6 support, are there any other big
things people would want that are none-the-less realistic and
not overly complicated?</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
ENet-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a>
<a class="moz-txt-link-freetext" href="http://lists.cubik.org/mailman/listinfo/enet-discuss">http://lists.cubik.org/mailman/listinfo/enet-discuss</a>
</pre>
</blockquote>
<br>
</body>
</html>