clientgen and cwd

[Andrew Tridgell]

> > > OH YEHHHHHH!  ok, next stage is to divide the functions out from client.c
> > > into clientgen.c so o have do_getcwd and cli_getcwd.  this makes client.c
> > > a little smaller and clientgen.c gets a bit unwieldy instead.  in
> > > BRANCH_NTDOM this prompted me to split clientgen.c down into about four
> > > modules: setup, print, ipc and file.
> > 
> > do we want clientgen.c to know about the current working directory?
> 
> hm, nooo... i created a "struct client_info" which contained all the
> global variables in client.c and a "struct client_tar_info" that contained
> all the global variables in clitar.c.

fine, but don't move them into clientgen.c

clientgen.c has a reasonable interface now, I don't think we want to
burden it with concepts that are alien to SMB (such as cwd).
 
> then: /tmp/foo
> s/tar_reset/smb_info.tar.tar_reset
> s/tar_inc/smb_info.tar.tar_inc
> ..
> ..
> 
> then:
> sed -e /tmp/foo client/clitar.c > client/clitar.c.mod
> sed -e /tmp/foo client/client.c > client/client.c.mod
> 
> then the same with client.c for cwd, recurse variables etc etc to
> smb_info.cwd.

I'm not really sure what that gains us. It would just mean that
instead of having several small global variables we have one large
one. That isn't really any better.

The right way to do this is to have structures that represent the
server context and structures for a file context. This is what I did
for smbwrapper, see "struct smbw_server", "struct smbw_file", "struct
smbw_filedes" and "struct smbw_dir" in smbw.h.

Each of these structures contain just the info they need to do the job
they are intended for, rather than containing the kitchen sink. Using
this design meant that having lots of simultaneous connections to
different servers, and different trees on those servers, was quite
natural in smbwrapper. It didn't involve any tricky coding. All
functions that deal with a file take a pointer to a "struct smbw_file"
as an argument, giving it access to all the info it needs to do the
job. Within smbw_file there is a pointer to a smbw_server structure
which in turn contains a pointer to a cli_state structure. 

If we are going to change the data structures in the client then
I think that something along those lines would be preferable, and
maybe we can even reuse the smbwrapper code to do it. What we can't do
is to use sed and expect to get a good result.

Cheers, Tridge