Wed, 2006-06-21 at 17:06 -0500, Gerald (Jerry) Carter wrote:
PGP SIGNED MESSAGE
Hash: SHA1

Mathias Dietz wrote:

The most important step is to define this management API and to
implement it inside samba3. Exporting this API via rpc is secondary.

Sorry. I disagree. just to make this clear, I believe MS-RPC
*is* the API. Why reinvent the wheel? Maybe we'll need to
have client RPC over unix domain sockets for local.

So the question is how do you use RPC before Samba is up
and running? The answer is a simple provision script.
I mean very simple. Just enough to get the server up
and have a single account.

SWAT would be ok for the first consumer / to polish the API.

Pleaseno. We need an API that will get used. SWAT
has its fingers in everything and is just broken as a
management tool.

Agreed. I'm all for ditching SWAT. There's an ocean of management tools
out there, both open source and proprietary. IMH, providing a rich
management interface for these is of more value than supporting SWAT.

James Peach :
Wed, 2006-06-21 at 17:06 -0500, Gerald (Jerry) Carter wrote:
SWAT would be ok for the first consumer / to polish the API.
>Pleaseno. We need an API that will get used. SWAT has its
>fingers in everything and is just broken as a management tool.

Agreed. I'm all for ditching SWAT. There's an ocean of management
tools out there, both open source and proprietary. IMH, providing a
rich management interface for these is of more value than supporting
SWAT.
So, let me round up this discussion:

1. Reviving SWAT in Samba 3 is pointless.
2. Better to concentrate on API for external management tools
3. Such an API is actually a set of MSRPC interfaces, including registry
management
4. Encapsulating those interfaces into a sort of library and providing
its bindings for popular scripting languages (Perl, Python, etc) is seem
of better value.
5. Additionally, local operation via Unix socket is probably a good
thing as user of that library and probably will be subject to test via
'make test'.

Anything else?

The problem we've had with Samba up until Samba4 is that it just wasn't
ready for an API. I've been trying to find the right way to APIify (if
that's a word) Samba since 1995, but the code base has always been
pretty monolithic. There was also the considerable problem in Samba2
and Samba3 of having the scads of globals that were required in order to
make any lib functions work for any management interface. With the work
that you've all done in Samba4 to get the globals cut out of the
picture, and with contexts, an API is now workable.

I've given an awful lot of thought to this over the last many years, and
there really are multiple paths that can be taken. path is to
create the monolithic library like we did in Samba3 and let anyone call
functions within that library. However, I'm not sure that makes a lot
of sense from a management perspective. From a management perspective,
we need a set of generalized calls for things like creating a user,
creating a group, adding a specific service (file or print), querying
status of the existing services, stopping, restarting, etc.

We need to think of EJS just as another client of the Samba4 library and
not as the encompassing management strategy for Samba4. It'll be great
having some of those functions available directly in the distribution
(when they're done) but we should be looking for more than that. We
need a library that allows for separation of Samba4 functions from
delivery, as well as allowing for multiple delivery paths and delivery
data types to be used. For example, if we want to allow someone to
create an AJAX frontend for Samba4, we'd need to provide an HTTP
delivery mechanism for retrieving pieces from Samba4. In that
particular case, we could reuse the existing SWAT HTTP engine, but link
it to the library and provide secure URL transactions through it, with
delivery in XML, XHTML, or even proprietary data sets.

With the library in place, bindings for Perl, Python, PHP, etc. would be
easily achievable. The API would probably end up looking a LT like the
Win32 API because, well, that's what we do. In fact, some 10 years ago,
I had proposed doing a CRBA object engine for Samba, but it just wasn't
ready for it at the time.

I still have some of my old documentation as well as some code I put
together for Samba2 and Samba3 that I can pull back out of the dust.
Let me know how I can help.
-- Dave

Thu, 22 Jun 2006 09:46:08 +0400, "Alexander Bokovoy" <ab (AT) samba (DOT) org>
said:
James Peach пишет:
Wed, 2006-06-21 at 17:06 -0500, Gerald (Jerry) Carter wrote:
SWAT would be ok for the first consumer / to polish the API.
>Pleaseno. We need an API that will get used. SWAT has its
>fingers in everything and is just broken as a management tool.

Agreed. I'm all for ditching SWAT. There's an ocean of management
tools out there, both open source and proprietary. IMH, providing a
rich management interface for these is of more value than supporting
SWAT.
So, let me round up this discussion:

1. Reviving SWAT in Samba 3 is pointless.
2. Better to concentrate on API for external management tools
3. Such an API is actually a set of MSRPC interfaces, including registry
management
4. Encapsulating those interfaces into a sort of library and providing
its bindings for popular scripting languages (Perl, Python, etc) is seem
of better value.
5. Additionally, local operation via Unix socket is probably a good
thing as user of that library and probably will be subject to test via
'make test'.

Anything else?