SoC: User Management Interface for SWAT (Samba 4)

[Rafal Szczesniak]

On Sat, Jun 03, 2006 at 10:00:01PM +0530, S P wrote:
> My SoC work will involve the following 3 components:
> 
> 1. GUI for User Management for SWAT 4
> 2. Javascript Library for User Management
> 3. EJS Plumbing for Samba 4 (where required)
> 
> I'll proceed bottom up:
> 
> 3. EJS Plumbing for Samba 4
> 
> This will involve writing the "plumbing" (EJS wrappers) so that
> JavaScript programs can access Samba 4 functions. Frankly, this is
> already done by others in the SAMBA_4/source/scripting/ejs directory
> (as I had expected). In particular the ldb functionality seems
> sufficient for user management, as far as I can tell.
> 
> Rafal: could you please tell me a little about libnet? You mention
> that I will be using it, but it looks like it is used for a remote SMB
> server. Also, ejsnet.c seems to wrap it. Does SWAT use this?

No, it doesn't yet. ejsnet.c was only an initial effort to test some
of capabilities of this technique. It will not be single-file implementation,
at least I hope so. It should wrap all libnet functionality in java script
library so that you can call all management functions using jave script
api. libnet can be used against remote servers, but only in those parts
using network layer to perform their actions (mostly rpc calls). There are
areas, however, that are to be strictly local - provisioning new samba4
servers, for instance.

> 2. JavaScript Library for User Management
> 
> This is a thin layer over the Samba EJS interface to make it
> convenient for JavaScript programs to access user management
> functions. In particular, its API will provide the following
> functionality:
> 
> 	    * Add users
> 	    * Set properties of a user
> 	    * Remove users
> 	    * Enumerate users

Actually, I expect this one to be ejsnet api. Right now, I don't see the
reason to implement yet one more js layer on top of ejsnet. Unless you
mean some utility objects/functions to make displaying or calling some
actions in more conveniently.

> It may turn out to be a very thin layer. In reality, I write this
> layer to get comfortable with the "meta" parts of the SoC project,
> including compilation issues, EJS API familiarization, and the _exact_
> (programmable) nature of my tasks. It also allows me to play separately
> with Qooxdoo and AJAX separately.

Ah, that's the case. OK, then - I don't know AJAX itself. I've had barely
basic contact with qooxdoo. What do you mean by "meta" parts, here ?

> The intended user of this layer is the GUI (which I'll be writing),
> but other scripts (non-GUI too) should also find it useful.
> 
> 
> 1. GUI for User Management for SWAT 4
> 
> This is the actual user visible part of the project, and the actual
> measure of the project's success. It consists of (simplistically) of
> two components:
> 
>    * User Browser
>    * User Properties Editor (for individual user)
> 
> This will most likely go from plain HTML to Qooxdoo or whatever
> graphical toolkit we will be using in SWAT. The recent discussion on
> the new qooxdoo branch was very informative, but I see difficulty in
> using it since I'm not re-writing SWAT, and other components in SWAT
> (esp. the registry editor) are already using an older version of
> qooxdoo.

Honestly, I'd love to see SWAT as one integrated qooxdoo (or AJAX) tool.
Perhaps with a simple html form in the begin just to login.

> Since I'll be working on this much later (July), I think we
> can discuss this later. Possible solutions look like use old, use new
> or use new+old together.

From my perspective, SWAT looks like a mixture of experiments done so far,
to find the technique we're all comfortable with. I wouldn't mind rewriting
some of them if there was a volunteer :) I may be wrong here, of course 
- don't let me misjudge someone's effort.

> MILESTONES:
> 
> M1: This involves completing 2 and 3. I'll have roughly about 14
> complete days for this. I should be able to demonstrate most aspects
> of the project in a non-GUI script.
>
> M2: This is 1, with modifications to 2 and 3 where necessary.
> 
> My apologies for the under-specification, I would have liked to
> provide API and code, but have not yet been able to look at the Samba
> 4 code at that level of detail due to my (still-ongoing) exams. But
> hope this clears up the nature and scope of my project.

Yes, so far your points look clear. You may be underestimating M1 here,
but it's difficult to predict it right now. We'll see.


cheers,
-- 
Rafal Szczesniak
Samba Team member  http://www.samba.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20060605/0046cb02/attachment.bin