Hi, Erik
Thanks for your suggestion. It's my pleasure to work with you:)
So, I'll do the following things:
1) Make a new branch named "experimental-udp", and only commit to this branch. 2) Do one feature at a time (now is UDP support) 3) Defer other part to the future (I'll try to research them in LispWorks-UDP package first, and then try them portable)
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).
Another way, "copy" more than a half source code of "lispworks-udp" into "experimental-udp" to avoid this "unnecessary" external dependency, but this will bring some issues to me and USOCKET:
1) "lispworks-udp" package has 730 lines' source code, and 500+ lines need to be copyed. Quite big for "backend/lispworks.lisp"
2) I have to maintain "two" UDP support code on LispWorks in the future. Any bug will be fixed twice.
So, at this "experimental" stage, I think maybe I should keep the lispworks-udp stuff outside first. When UDP on all support CLs are working, you can help me to decide whether to keep this additional dependency or not.
Regards,
Chun Tian (binghe)
在 2008-10-3，4:51， Erik Huelsmann 写道：
On Thu, Oct 2, 2008 at 6:34 PM, Chun Tian (binghe) binghe.lisp@gmail.com wrote:
Hi, usocket devel (Erik and Hans)
(sorry for my poor English first)
As you guys already know, I'm working on some UDP-relate packages' development, and already got a working UDP patch for usocket project.
Yes. It's really exciting that you've been working on such new features.
I also want to do more on this area (portable Common Lisp networking), following is my interesting part:
- UDP (already have some code)
- ICMP (ping)
- UDP Multicasting
If I'm allowed to split up the list, I think the items mentioned above are protocols (such as TCP), while the item below is a transfer 'method' (TCP/IP vs UNIX Domain Socket). Would you agree?
- UNIX Domain Socket (AF_LOCAL)
I want to stay in the framework which USOCKET already have, and try to extensive it to support more features.
Thanks! :-)
Erik agreed to give me SVN commit access and now I wish to open a new branch for above experimental work. As the first mission, I'll merge all my UDP patch into this new branch.
That's great. How about a branch named 'experimental-udp'?
However, one thing I tried to do is to keep things as 'tcp/ip' and 'udp' out of the sources/apis; instead, I took the more abstract transport types 'stream' and 'packet' to work with those. The consequence should be that the use of usocket isn't restricted to internet sockets and tcpip/udp transports, but can also implement (later) ATM or Unix domain socket transports with stream and packet transfer methods.
I think a branch with name "udp" or "binghe" (like the "hans" branch before) will be OK, but as a new member I don't think I should make this branch by my self (that's not quite polite, I think). So I'm looking for opinions or a branch made by Erik for me to commit codes.
Be my guest and open a branch for the UDP work. If you don't mind, I'd like to see work focussed on 1 subject at a time for now: we're only a small developer community and spreading our attention means the risk of delivering nothing. So, if you could defer the UDP multicast and Unix domain work for a while, that would be great!
Branching off of the trunk seems the best to me. If any commits happen on trunk, you could merge them, if that's required for your branch.
Thanks for taking on this enhancement! It's greatly appreciated.
Bye,
Erik.