Future and plans for libnet? Why 'all the way with ejs'?

[tridge at samba.org]

Andrew,

 > I'm wondering, given all the attention being put into Samba4's embedded
 > scripting language (to support swat), what the future of libnet is?

I am hoping that Mimir (or someone) will build ejs interfaces for
libnet.

 > It seems that libnet is slowly being replaced by ejs, and that the
 > emphasis is on SWAT being the admin tool-centre rather than net.  Is
 > that an accurate description of where we are going?

I certainly want our web management interface to be good enough that
everyone, even experts, will want to use it. 

One thing we could consider is replacing the current C version of net
with a ejs script. Similarly, I think that smbstatus, rpcclient and
smbclient should be scripts. The only big missing piece to doing this
is a readline() call in ejs, and that is certainly easy to add.

This isn't the reason I am working so much on ejs right now
though. The incentive for my current efforts is to build it up enough
that we can build a rich web management interface, and in particular
build interfaces to irpc calls, so the web interface can call into our
various server structures to control the running smbd daemon. 

A side effect of this effort is that we can create powerful command
line interfaces as well, and I definately would like to take advantage
of that.

 > Likewise, what has happened to python?  ejs is fine (I suppose) for our
 > internal use, but isn't part of the idea with Samba4 to be open and
 > easily extended beyond Samba?

Until ejs we never had a scripting language that we could assume all
installs of Samba would have (apart from bourne shell). So while the
python interfaces to our libraries were a neat idea, we could not
build core tools like smbclient or smbstatus in python, as we would
then also need to maintain C versions for platforms where python is
not installed.

I also want to get rid of our runtime dependence on perl. I don't mind
using perl for building Samba4, but using it for our installation code
(specifically provision.pl) is a bad idea I think.

A first step towards this will be to be able to provision/install via
the web interface, but by writing the code that does that as ejs
functions, it will be just as easy to have a command line provisioning
script in ejs as well.

We have nearly all the pieces in place to do this now. ejs scripts can
access smb.conf, can access ldb and can make any rpc call. So
replacing provision.pl with a ejs script should not be hard. It should
also be a lot cleaner, as the current provision code forms a ldif file
then calls out to the ldbadd binary, whereas ejs can directly make ldb
calls inside the script.

Cheers, Tridge