inspired by the web server in Samba 4

Sat Jun 4 15:19:54 GMT 2005

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think you missed the point of my proposal.  It is a
social experiment, not necessarily a technical one.
It has nothing to do with the technical nature of ejs.
I'm just curious about the deployment of ejs developers
vs. the adoption of a solution built using component
with which people are already familiar.  Maybe it will
be a bust.  Maybe I'll come to agree that your solution
is better.  Who knows?  This is kind of like the yodl
vs. docbook debate.  One is extremely simple and
easy for us to use where as the other is more familiar
to people outside Samba.

My goal with google's program is first of all to
create more open source programmers (hopefully working
on Samba).  There is no guarantee that any of the projects
completed over the summer will be officially released
and supported.  Who knows?  We might get lucky on some.

So this is a chance to experiment with some ideas
that I do not have the time to do myself.  If you change
your mind and decide that you would like to take on
some of the applicants to experiment with ideas for
Samba 4, then cool.  That would be great because
I'm not plugged into Samba 4 enough to be able to come
up with ideas.

| Using mod_python+apache would also present a considerable
| license problem. Our web management interface needs
| deep access to smbd structures, and that means linking
| to a lot of Samba code.

I'm don't want to link mod_python to smbd.  A management
app does not necessarily need to link with Samba code.
In fact, an argument could be made that it shouldn't.
For example, if a management app needs to know the
layout of a tdb record, then you are locked into step
~ upgrades.  The app must be updated with Samba.  There
are other interfaces that will not or cannot change
(e.g. smb.conf, rpc, etc...).  That is interesting from my
point of view.

So licensing should not be an issue given this separation.

I think that Samba/Apache/mod_ssl/mod_python installs
can be streamlined enough for the install process to
be fairly simple.  IMO that's what package management
tools are for.  We just disagree here.  It's a different
approach.  That's all.  The only way to know if something
can be done and works is to try it.  So I'm going to
accept google's offer and spend some time on it.

| and that is it as the user is thrown into a install wizard.
| Complex instructions about setting up apache with a
| modified mod_python to talk to smbd internals, plus setting
| up apache https would increase the barrier to entry a lot.

Maybe.  But people know apache already. And people know
python.  We'll see what happens from there.  I've got some
interest from applicants on several projects now.  If I
have to loose some of my own productivity to help
coordinate 5 - 6 other people working on Samba, that is
an acceptable sacrifice even if the end result is to know
that something doesn't work.

If we get even one more long term good developer (or even
just while they are in college), then it will have been worth
it.  Working on Samba has made my life better. It is an
extremely enjoyable experience.  I think that other people
should have the same opportunity and so I want to help expose
them to it.

cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCocaaIR7qMdg1EfYRAv+AAKCaF+kxH9kfwaQ7OHa63FlHuMVkgQCgoC2T
ybiAcFTq1GSoZBwO9j3gZKo=
=dPAm
-----END PGP SIGNATURE-----