[usocket-devel] Request for new experimental branch about UDP and others

[Chun Tian (binghe)]

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 at 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.