[Usocket-devel] [usocket-devel] IPv6 support in usocket

[Hans Hübner]

I did some more research to find that nothing has moved in terms of
implementation support for IPv6 (in SBCL and CCL, fwiw).  I think this
should change, in particular as the required changes to sb-bsd-sockets and
l1-sockets.lisp are rather small, and it is very embarrassing that the two
most popular open source CL implementations still ignore IPv6.

I'm going to come up with a more complete IPv6 update to sb-bsd-sockets in
the next few days and try to get it merged into SBCL.

>From looking at
http://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/4E820C9E-33E2-43B2-BA2F-566F812AB154@gmail.com/,
I see that there has been some work on USOCKET to support IPv6.  Has that
gone anywhere yet?

Finally, would you consider moving USOCKET development to git?  GitHub
makes collaboration so much easier.

Cheers,
Hans

2014-09-17 9:36 GMT+02:00 Hans Hübner <hans.huebner at gmail.com>:

> Hi Chun,
>
> this discussion thread has kind of ended in nothing and I'm now returning
> to find out how IPv6 support can be added to Hunchentoot and Drakma.  A few
> options are on the table:
>
> - Make USOCKET support IPv6
> - Create IOLib backend for USOCKET
> - Add Implementation specific code to Drakma and Hunchentoot
>
> I have given up on the IOLib idea, basically because it uses a shared
> library that cannot be built using quicklisp.
>
> What is the status of IPv6 support in USOCKET?  Is there any hope to see
> it happen?
>
> Thanks,
> Hans
>
> 2013-06-25 15:12 GMT+02:00 Ryan Davis <ryan at acceleration.net>:
>
>>  We have a similar problem with CLSQL; one API with multiple database
>> backends. CLSQL's backend choice is a little different; the backend choice
>> is a user-facing decision whereas usocket choosing iolib is an internal
>> matter, but I thought I'd offer our approach.
>>
>> We solve it in two ways:
>>
>>    - an ASD files for each backend: clsql-mysql, clsql-sqlite3, etc.
>>    (akin to the proposed usocket-iolib)
>>     - a generic ASD file that tries to dynamically load more backends on
>>    request; if we try to connect to a :sqlite3 database, the connect function
>>    checks to see if clsql-sqlite3 is loaded, and if not, issues the load on
>>    the spot - see
>>    https://github.com/UnwashedMeme/clsql/blob/master/sql/database.lisp#L99
>>
>> So library users can specify which backend they want via a direct
>> dependency via ASDF, or let the environment take care of it. It's not the
>> cleanest solution in the world and has some restrictions, but it's worked
>> pretty well.
>>
>> Thanks,
>>
>> Ryan Davis
>> Director of Programming, Acceleration.net
>> 2837 NW 41st Street, Unit 320
>> Gainesville, FL 32606
>> 352-335-6500 x124http://www.acceleration.net
>>
>> On 06/24/2013 06:27 AM, Chun Tian (binghe) wrote:
>>
>> Hi Anton
>>
>> On 24/giu/2013, at 18:10, Anton Vodonosov <avodonosov at yandex.ru> <avodonosov at yandex.ru> wrote:
>>
>>
>>   To solve all related issue, I'm going to do some runtime detection on *features*: if last compile time usocket was compiled with or without :usocket-iolib but current load time the feature set is different, ASDF should re-compile all usocket source files instead, not just load previous FASLs.  (I'm not sure if ASDF have already provided such a feature, so let me also copy this mail to Faré, the ASDF maintainer)
>>
>> I don't like the idea of creating a whole new ASDF system like "usocket-iolib", because that will require other packages to change their system definitions to benefit from this new work.  And the most important thing, whether to depend on IOlib is totally an internal fair of usocket: it doesn't change the programming interface at all.  And the choice on if user want to use native network support of IOlib-based network support on their current platforms, ONLY depends on if they like to load additional DLLs (by CFFI).   I always want usocket  to depend on nothing, so that we can easily patch those 24x7 lisp servers to upgrade the networking support smoothly.
>>
>>  I agree that the usocket clients (application and other libraries) should work via the API and do not depend on particular implementation.
>> What I suggest is to make the implementation switchable at runtime, instead of compile time. I think the solution will be simpler and more flexible solution.
>> Up the the level that we can have at the same time in the same lisp image both IOlib sockets and sockets based on the API provided by the Lisp implementation.
>>
>>  It's possible to implement the runtime switches, and I admit this is a good idea when IOlib is being depended by usocket.   Now I think it's also possible to provide a standalone, new ASDF system "usocket-iolib", which *explicitly* make sure IOlib is used as backend.  But all my previous ideas should still work, there's no conflicts I can see.
>>
>>
>>  Best regards,
>> - Anton
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/usocket-devel/attachments/20140917/b891e0e9/attachment.html>