[ds6-devel] Re: new refactor code

[Chris Leishman]

On Monday, January 13, 2003, at 03:26 AM, Mauro Tortonesi wrote:

>
> chris,
>
> 	your code still does not solve all the problems. DO NOT get
> offended, but there are some things i don't like:

I try never to get offended.  And sorry if I stomp around a bit - I 
don't mean to offend!


> 1) removal of setup_{local,remote}_stream

Well...there's no reason these can't go back in.  My implementation 
didn't need them (there's nothing to do that ios_assign_* can't do), 
but if you want them in, thats fine.  The setup_local_stream will be 
useful for --exec for sure, though I'm not sure what 
setup_remote_stream will do...

> 2) passing socktype as the second argument of do_{connect,listen} is
>    really awful IMVHO, and should be avoided at all costs

Well, do_connects and do_listens job is to create a socket (the fd) and 
to tell us what sort of socket it is.  So it needs to return those two 
values.  I'm not really sure how else to do it, and return via 
reference is pretty common in that situation - especially when the 
"other" value is optional (see recv(2), adjtime(2), utimes(2), 
getdirentries(2), getfh(2), getgroups(2), etc, etc)

Of course, we could get really radical and just throw out the socktype 
type from the io_stream all together....  At the moment it's only used 
for calling cb_read v's cb_recv - and on connected UDP sockets we can 
actually use cb_read as well.....so there's no need to differentiate.

> 3) the if (very_verbose==TRUE) code included in establish_connection
>    should be moved to do_listen and do_connect

Well, I guess thats a matter of taste.  I liked the fact that most of 
the very_verbose output (all the pre-transfer stuff at least) is out of 
the network code - it makes the network code clean and reusable.

I'll also make a confession - I'm thinking ahead for when we want to do 
some more funky things with continuous modes, etc.  We really want most 
of the flags to be specific to a single connection - all except the 
logging ones, verbose and very verbose.  All the other flags relate to 
the connection_attributes in some way, and probably should eventually 
be moved into there.

Once thats done, everything the network code needs to do it's job will 
be inside the ca, and there will be no need for any other external 
flags, etc.

But if your keen on this, it's no big deal.

> for the rest the code is sure better than mine, as the level of 
> nesting is
> by far less and it does not break the exit code passing.

thanks :)


Regards,
Chris