Hi binghe,
you are welcome. Both iolib and usocket seem to be under the MIT
licence so I don't see a problem on that front.
However, shouldn't the code be merged into iolib only rather than
merging it into both iolib and usocket? The whole of the iolib winapi
port makes it quite a lot of code. It would be a shame to sacrifice the
winapi part especially when usocket is all about portability API.
Also, as Anton pointed out, I find a separate system better solution
than pushing a feature. After all, usocket is an API. When implemented
using iolib, why would there be a need to use any code from the original
usocket? At the moment we simply asdf-load :iolib.usocket only and all
systems depending on usocket work as desired because the required
usocket system and usocket:* stuff is in place.
Cheers,
Tomas
On 06/24/2013 11:33 AM, Chun Tian (binghe) wrote:
Hi Tomas
Thank you! Then I guess you wouldn't mind if I merge your work into usocket as
the basis of the new IOlib backend? ^_^
--binghe
On 24/giu/2013, at 17:30, Tomas Hlavaty <tomas.hlav...@knowledgetools.de> wrote:
Hi all,
just in case it might be somehow interesting, we've had iolib.usocket system
for quite some time in http://src.knowledgetools.de/tomas/winapi/index.html It
is a simple usocket compatibility layer on top of iolib (also works on Windows
winapi 32 and 64 bit). Not sure what the ipv6 status is though as we don't use
that. IIRC I still need to implement translation of iolib conditions to
usocket ones, but as a precondition for that is unifying conditions from iolib
posix and winapi backends. Otherwise, hunchentoot and cl-postgres work well on
posix and windows using this compatibility layer.
Cheers,
Tomas
On 06/24/2013 11:12 AM, Anton Vodonosov wrote:
Hello.
24.06.2013, 11:22, "Chun Tian (binghe)" <binghe.l...@gmail.com>:
To compile usocket with IOlib, user should push :usocket-iolib into their
*feature* first.
I would like to propose to use some other solution than conditional controlling
compilation with *reatures*.
The disadvantage of the conditional compilation is that when my application
loads the usocket
as a dependency, the application doesn't know how usocket will work, because it
was dediced
when usocket was compiled (possible during load of some other application).
If you give little bit more details about he usocket-iolib functions, I can
propose more concrete solutions.
Very possible the proposal will be a separate ASDF system, usocket-iolib.
Best regards,
- Anton
