24.06.2013, 13:30, "Chun Tian (binghe)" binghe.lisp@gmail.com:
Among all those famous ASDF-based packages, I see hunchentoot also used the same approach to compile a special version with SSL support: by pushing :hunchentoot-no-ssl into *features*, hunchentoot can be compiled successfully on platforms (like the old MCL) where CL+SSL is not available yet, or when user simply don't need SSL for their web servers.
Yes, I know how this pattern is used in hunchentoot.
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.
Best regards, - Anton