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 <r...@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 <avodono...@yandex.ru> > <avodono...@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 > > >
_______________________________________________ Usocket-devel mailing list Usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
