[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