[usocket-devel] Request for new experimental branch about UDP and others
Chun Tian (binghe)
binghe.lisp at gmail.com
Fri Oct 3 09:03:45 UTC 2008
>
>> 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)
More information about the usocket-devel
mailing list