There's still one thing I don't know how to decide, need your opinion:
On LispWorks, there's no official support on UDP, and my LispWorks- UDP package is quite successful to let people doing UDP job (there're some real customer whom use it in production environment). Obviously I should continue maintaining this package for those whom only writing applications on LispWorks.
For usocket UDP networking on LispWorks, there're two way to merge my work:
One way, let usocket depends on the exist "lispworks-udp" package (just like the way usocket-udp does).
For as long as this feature is experimental - and the fact that no other package provides lispworks-udp - I think it's fine to depend on lispworks-udp. However, if we decide we want to move code to usocket, there's a coding pattern I'm not very much at ease with in lispworks-udp (or, at least, there was such a pattern): you're invading into an implementation defined/ provided package to define functions of your own.
As I said, for the purpose of our experimental branch, that's no issue.
You're right: I shouldn't put my own functions into LispWorks' COMM package.
When I first wrote lispworks-udp, I just thought that would be quite easy to use COMM's internal symbol and functions. When lispworks-udp grow bigger, I regretted. So, in my next major release of lispworks- udp (4.0), I decide put all my code into a new package "COMM+" and import all external functions of LispWorks' COMM package, so that people just do a package name change from "COMM" to "COMM+" would done the whole port job.
Regards,
Chun Tian (binghe)