Management of Samba

[Luke Kenneth Casson Leighton]

<a href="mailto:lkcl at samba.anu.edu.au" > Luke Kenneth Casson Leighton  </a>
<a href="http://mailhost.cb1.com/~lkcl"> Samba and Network Development </a>
<a href="http://www.samba.co.uk"       > Samba and Network Consultancy </a>

---------- Forwarded message ----------
Date: Tue, 24 Mar 1998 19:54:53 +1100
From: Dave Fenwick <djf at assetsw.com>
To: Multiple recipients of list <samba-team at samba.anu.edu.au>
Subject: Re: Management of Samba

>> > > This means that what is required is a freeware ORB that can be
distributed
>> > > with Samba or pointed to by the distribution that has a C IDL for two
>> > > reasons:
>> >
>> > yikes! We are not going to distribute an ORB with Samba. We have
>> > enough problems maintaining a SMB server :-)
>
>I didn't really think you'd like option one (do you kow how big an ORB
>is?? Usually very fat) but option two is perfectly feasible. A C IDL
>definition compatible with one or more freeware ORBs would be a trivial
>addition to the source directory. Dave, does this fit with what you had in
>might?

Somewhat, I should say.  The way I look at it, people are looking for
several things:

1)  An easy means of doing Samba admin straight from the distribution
2)  An extensible administrative back-end for Samba
3)  An extensible administrative front-end for Samba
4)  Specs for everything

(1) can be handled with SWAT, although most administrators would agree that
it is not as simple to use as it could be - And never will be overly simple
due to gaping holes in HTML that reduce functionality.

(2) is what we're talking about now.  I think we could put together a
relatively robust interface and provide specs for other software needed
(Apache?  ORB?) to make it work.

(3) we would provide at least some level of interface, and let developers go
where they will with it.  Perhaps providing the mod-jserv with our servlet
and some level of how things work might be sufficient.  Also, providing a
Java front-end that talks directly to the ORB might be a good thing too.
This would show people how to directly tie to the ORB rather than through
the web server.

(4) is what I'm trying to ascertain now.

As far as ORB implementations, I've been using OmniOrb (GPLed, etc.) to do
most of the server-side stuff I'm doing.  It has proved to be quite nice for
everything it's done.  They claim it is the fastest ORB on the planet, and
based on the testing I've done, they seem to be right.


Now, to try and persuade Andrew to update his Computer Science thinking into
the 1990s <<< GRIN >>>  :-)

You are absolutely right in your thinking of not bundling EVERYTHING in
Samba.  However, it *could* be an option.  Any time a vendor (I consider us
a vendor these days - we provide a service for others, including
functionality, support, and bug fixes) gets to the critical mass level,
their distributions generally start growing.  Microsoft provided a decent
level of functionality in LANMAN, but the interface was brutal.  When the
Windows Networking approach hit, it was better, but still painful.  With NT,
it provided additional functionality including administrative interfaces,
and the distribution grew significantly.

Having said this, I don't believe we should provide all the pieces in our
distribution.  The elements I believe we should provide would be:

-  A Java servlet element for the mod-jserv in Apache that talks to our
CORBA objects
-  A CORBA IDL that can be compiled with whatever IDL interface the user
has.
-  The user interface elements for the Java servlet implementation
-  A Java application or applet that shows how to directly tie in to the
Samba CORBA objects
-  Links for where to get all the other pieces needed to implement this
functionality (Apache web pages, OmniOrb web pages, etc.)

I've been down this road before.  When deploying any significant web or
CORBA engine, there are always third-party tools that seem to be necessary
to fully implement the interface.  Specifying the required third-party
tools, but not distributing them with your sources is simple and reduces the
distribution size for your software.

Now, the last convincing argument for CORBA - IIOP.  I've written a lot of
sockets code over the years.  Both Unix BSD sockets and Winsock
applications.  Writing any significant interface with either requires a good
deal of time.  Generally, you pull some previous sources you have laying
around, delete out the things that make it specific, and implement the new
functionality from there.  Then you have to invent some type of protocol at
layer 5 to implement your interface.  With IIOP in CORBA, all of that is
already taken care of.  You implement the work you want to do, and it's
done.  It has saved me CONSIDERABLE amounts of time, simply because I don't
have to fuss with the layer 5 implementation.  All I deal with is the
objects themselves, and not the underlying network interface
implementations.  You must agree, this is a good way to do business.
Abstraction is good.

-----------------------------------------------------------------------
David J. Fenwick                                        djf at assetsw.com
Nomadic Developer                                  Asset Software, Inc.