CVS update: samba/source/ubiqx

[Christopher R. Hertel]

Andrew,

This is really going to be tough, isn't it...

> > The reason that I object is that I think that the ubiqx modules, and parts
> > of the "main" Samba code, should be able to stand alone.  
> 
> how about:
> 
> #ifdef SAMBA
> #include "../includes.h"
> #else
> #include <some_system_includes>
> #endif

Nope.  Unless you want to copy the ubiqx code and maintain it as a
separate stream (which we can certainly do, it's just a maintenance
nightmare), then I don't want to need this kind of thing.  I'd really 
like to make sure that the modules can stand alone.  If I do this for 
Samba, how many other packages that use the ubiqx stuff will want their 
own #ifdef???

> the problem with your suggestion is maintainence.

Funny, that's just what I was thinking about your suggestion.

> Using includes.h
> guarantees that if one module in Samba is OK for includes then all
> are. It is a nightmare trying to do include files in every module. I
> know you could get it right for specific cases but for every case? You
> will end up as complex as includes.h.

I think you're thinking monolithically.

> quoting K&R doesn't really solve the problem. What about the Amiga,

Tested.

> OS/2, Novell and VMS ports? What about XYZ port in the future?

The ubiqx stuff needs to be portable to these platforms anyway -- on it's 
own.

> > Mangle.c, for example, would be great as a stand-alone module.  It
> > should not depend upon the rest of the code to work.  I'm also
> > thinking about the smb.conf parsing and config database management
> > in these terms.  Make this *really* re-usable code.
> 
> nope. It's a marvelous idea but it won't work until we go to autoconf
> and standardise on HAVE_XXX style stuff. Even then we will need the
> equivalent of includes.h to handle the nightmare of conflicting
> include files.

Again, I believe that you are thinking in terms of the whole, and not the 
pieces.  It's worth while knowing what each module needs, and from where 
it should get what it needs.  Really.

> Reusable code (in the sense of taking a whole file and putting it in
> another package with no changes whatsoever) doesn't exist.

Oooohh.  Sure it does, or at least we can come quite close.  Perhaps it is
asymptotic as you suggest.  That doesn't make it futile to attempt.

> You can almost do it with very simple code that calls very few 
> functions. With code that calls lots of functions it doesn't happen
> at all.

That's why you modularize.  Put the simple code into modules and put the
code that calls all of the functions, including the module functions,
system functions, standard C functions, etc., into main program files.  

The code in the ubiqx/source directory consists of "very simple code that
calls very few functions".  In fact, there shouldn't be any calls to
outside functions.  I designed the modules to work without having to
reference anything outside.  The one clear exception would be NULL (which
isn't a function). 

....

So, the ubiqx modules are supposed to work on just about any platform. 
The one sticking point is the definition of NULL (and I do thank you for
pointing that out).  For those modules (the ubiqx modules) the *only*
portability issue (of which I am aware) is selecting the correct include
for obtaining the platform's definition of NULL. 

I don't see why we should need to create a separate strain and additional 
maintenance track just to handle this one issue.

Let's keep this conversation going until we have some sort of agreement.  
I'd like to make sure we're working toward the same goals here.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services