the client

[Luke Kenneth Casson Leighton]

i hate clientutil.c.  you produced clientgen.c from it: i liked this.  i
took your work a step further, did a split-down similar to what you did
with server.c, did some code-topology-restructuring involving parameters
(struct client_info and others). 


 

On Thu, 20 Aug 1998, Andrew Tridgell wrote:

> We need to work out what we are going to do about smbclient.
> 
> Right now we have several code sets:
> 
> 1) the head branch. The code is very messy and badly designed but does
>    generally work. It uses clientutil.c as its "library", although it
>    does most SMB stuff inline by writing into a packet buffer.

> 2) the ntdom branch in sambaold. This one was done primarily by
>    Luke. It is nicely structured. It splits the client code into
>    sections and uses Lukes varient of clientgen.c. It has the nt rpc
>    client stuff, which allows you to do all sorts of nice stuff with
>    pipes. It has not been autoconf converted and many bugs we have
>    fixed in the main branch are not fixed here.

damn.
 
> 3) clientgen.c in the head branch. This was my attempt at a set of
>    basic SMB client functions in a library-like format. All the head
>    branch client calls are made via this code _except_ for those from
>    smbclient! My plan at the time was to convert smbclient to use this
>    code. I never got around to it.

i did that for you, in BRANCH_NTDOM smbclient.
 
> 4) the 1.9.18 branch in sambaold. This has some bug fixes from
>    Richard.

damn.
 
> As I see it we have a number of choices:
> 
> 1) dump the head branch client code and replace it with Lukes
>    code. This is harder than it sounds because it means reconciling
>    the differences in clientgen.c between the two versions. It also
>    means re-fixing all the bugs that have been fixed since the ntdom
>    split. some cvs history might help with that.
> 
> 2) convert the head branch to use clientgen.c and do some
>    restructuring so it becomes maintainable.

> This means losing the nt client stuff luke has done.

no, that is not a viable option.  no work is possible on dce/rpc without
this code: it's a) an integral part of the bootstrap process b) intended
to be wrapped in perl or cgi scripts, for producing dce/rpc admin tools
for samba/unix and nt servers/workstations.

> 3) write a new smbclient from scratch.
> 
> I think the best option is (1). Anyone else have a suggestion? 
> 
> Whatever we do it will be quite a lot of work. I started to do (1)
> last night but gave up when I realised I couldn't get it done in the
> couple of hours I had available. The hard bit is reconciling the
> clientgen.c differences.

yes, it's going to be tough.  another option: take the added
nt-dce-rpc-client commands, and "add" them again to the current smbclient.
modify the smb <-> rpc-client interface so that the two sets of code can
be butted together.

another option: produce a diff on the main-branch version of smbclient 
from back when volker added the smbmount / smbumount code.  i was keeping
up-to-date from then.  cut this into the BRANCH_NTDOM smbclient code, by
hand.

personal opinion: preferred option, (1).  *BUT* before doing it, please
could you remove all references to t_idx and the tcon[32] array i put in
there.  with sed applied to all files, this should take about 15 / 20
mins.  jeremy knows the details, and i sent him and samba-bugs i think a
patch back in... february? march?


lesson 1) learned from this: i don't want to be involved in writing any
code for samba in a different branch that crosses from one alpha series
release to another.  in other words, we never do an alpha release until
all branches are merged.  if this delays the start of a new alpha release,
so be it. 

lesson 2) if someone is adding new features while someone else is working 
on a branch, either a) don't, until a merge is done b) add the new feature
to _all_ branches, or no branches.  chris, for example, held off doing his
ubiqx mods to nmbd until jeremy had finished and merged his nmbd rewrite
branch.

luke