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. 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 * 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. 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.
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.
Regards,
Chun Tian (binghe)
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.
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.
On Fri, Oct 3, 2008 at 1:09 AM, Chun Tian (binghe) binghe.lisp@gmail.com wrote:
Hi, Erik
Thanks for your suggestion. It's my pleasure to work with you:)
So, I'll do the following things:
- 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)
That looks like a good plan.
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.
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:
- "lispworks-udp" package has 730 lines' source code, and 500+ lines need
to be copyed. Quite big for "backend/lispworks.lisp"
- I have to maintain "two" UDP support code on LispWorks in the future. Any
bug will be fixed twice.
That depends :-) You can also change the dependencies: make lispworks-udp depend on usocket-udp by implementing it on top of usocket. That would mean that you've made lispworks-udp portable to other platforms :-) Seriously: we'll see. There's little use of duplicating lots of code in both packages. [OTOH, I'd rather not depend on too many non-standard packages...]
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.
That's going to be the plan, like you propose. Thanks again for your continued efforts!
Bye,
Erik.
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)
-
Chun Tian (binghe) -
Erik Huelsmann