python-ldap-dev

Roadmap for ldapmodule

[Michael <mi...@st...>]

HI!

I see a strong need for a defined roadmap for python-ldap. The
current situation on the web pages looks rather confusing for users
of the ldapmodule.

Some suggestions (and I hope some silent readers of this list jump
into this discussion):

1. Module names (high priority):
--------------------------------
When renaming was done from ldap to _ldap I did not thought about it
thoroughly enough. But now it seems to me that it breaks a lot of
existing code and produces much confusion when updating. There are
some web articles describing example code etc., too (e.g.
http://www.sunworld.com/sunworldonline/swol-01-2000/swol-01-ldap3_p.html).
E.g. S.u.S.E. delivers ldapmodule 1.5 with their Linux distribution
and it's much easier to explain users how to upgrade if the old
naming is used.

Please, rename _ldap back to ldap and rename Fog's stuff to
LDAPObjects, ldapobj, ldaplib or a similar name since Fog's stuff is
not widely used or documented up to now.

2. CVS (high priority):
-----------------------
The CVS repository is not very clear for newbies who don't know the
history.

ldap-module/

Seems to be the old stuff. We should get rid of this directory
completely to avoid confusion.
 
python-ldap/ldaplib/
python-ldap/ldapmodule/

These both directories should be at top of CVS tree since the
project is already called python-ldap. A sub-directory python-ldap/
seems redundant if ldap-module/ is removed. BTW: ldapmodule and
ldaplib should be distributed in separated release packages.

IMHO the CVS repository could be simplified and expanded to

htdocs/
ldaplib/
ldapmodule/
applications/
demos/

New directories applications/ and demos/ should be created for
existing applications (e.g. Fog's lappo going into
applications/lappo/) and small example code snippets for tutorial
purpose going into demos/.

3. Release of C-module (high priority):
---------------------------------------
Make a new stable, well tested and compatible release of the C
ldapmodule AS SOON AS POSSIBLE and publish it on the SourceForge web
page. Especially the fixes for memory leaking etc. are important for
serious application developers. This could contain Fog's stuff
marked as still being experimental.
This is highly needed as a base for package maintainers like
mir...@in... (see Red Hat-packages on
http://www.webideal.de/ldap/) or S.u.S.E (I will trigger them both).

4. SSL (medium priority):
-------------------------
There are a lot of applications where confidentiality of transmitted
data has to be guaranteed => LDAP over SSL is highly needed.
ldapmodule can be linked to Netscape SDK which has SSL support. Also
it's worth looking at OpenLDAP 2.0's new API because this will be
the new standard API for LDAP. Although I can't help with C
programming I can help with investigating the needs for certificate
handling etc.

5. LDAPObjects (low priority):
------------------------------
We have to review Fog's work (hopefully I have the time!) to
establish a standard Pythonish, re-usable and robust class library
for LDAP applications.

6. Distributing with Python's standard lib (low priority):
----------------------------------------------------------
Although G.v.R. seems to be not very open for third-party modules we
should have the goal to integrate the whole python-ldap stuff into
the Python standard distribution because LDAP is a protocol which
gets more and more important for application developers (e.g.
regarding single sign-on environments, Win2000 Active Directory
etc.).

Please, let me know what you think.

Ciao, Michael.

Re: Roadmap for ldapmodule

[<fo...@mi...>]

Scavenging the mail folder uncovered Michael Ströder's letter:

> Please, rename _ldap back to ldap and rename Fog's stuff to
> LDAPObjects, ldapobj, ldaplib or a similar name since Fog's stuff is
> not widely used or documented up to now.

standard for python extension written in C is _ldap in a ldapmodule.so
library. if you simply do an "import ldap" you automatically get a
"from _ldap import *" and all the previous code continues working.
**no need** to change a single line of code.

> 2. CVS (high priority):
> -----------------------
> The CVS repository is not very clear for newbies who don't know the
> history.
> 
> ldap-module/
> 
> Seems to be the old stuff. We should get rid of this directory
> completely to avoid confusion.
>  
> python-ldap/ldaplib/
> python-ldap/ldapmodule/
> 
> These both directories should be at top of CVS tree since the
> project is already called python-ldap. A sub-directory python-ldap/
> seems redundant if ldap-module/ is removed. BTW: ldapmodule and
> ldaplib should be distributed in separated release packages.

i agree.

> New directories applications/ and demos/ should be created for
> existing applications (e.g. Fog's lappo going into
> applications/lappo/) and small example code snippets for tutorial
> purpose going into demos/.

i would better like to keep code snippets and applications (lappo)
requiring ldaplib under ldaplib. else an user will download the C 
module and demos only and then write us the the demos do not work...

> 5. LDAPObjects (low priority):
> ------------------------------
> We have to review Fog's work (hopefully I have the time!) to
> establish a standard Pythonish, re-usable and robust class library
> for LDAP applications.

i agree (on the review part.) my work on LDAPObject is stalled mainly
because i received no input and (apart from lappo) i don't use my
own code very much (waiting for ssl, then we'll move all out ns to ldap
and will be a different story...)

> 6. Distributing with Python's standard lib (low priority):
> ----------------------------------------------------------
> Although G.v.R. seems to be not very open for third-party modules we
> should have the goal to integrate the whole python-ldap stuff into
> the Python standard distribution because LDAP is a protocol which
> gets more and more important for application developers (e.g.
> regarding single sign-on environments, Win2000 Active Directory
> etc.).

i don't agree on that. distribution makers like redhat or debian will
bundle python-ldap anyway. ah! and Win2000 Active Directory is not
compatible with standard ldap...

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
                           Don't dream it. Be it. -- Dr. Frank'n'further

Re: Roadmap for ldapmodule

[Michael <mi...@st...>]

Federico Di Gregorio wrote:
> 
> Scavenging the mail folder uncovered Michael Ströder's letter:
> 
> > Please, rename _ldap back to ldap
> 
> if you simply do an "import ldap" you automatically get a
> "from _ldap import *" and all the previous code continues working.
> **no need** to change a single line of code.

Oh, I see. Didn't know that.

> > New directories applications/ and demos/ should be created for
> > existing applications (e.g. Fog's lappo going into
> > applications/lappo/) and small example code snippets for tutorial
> > purpose going into demos/.
> 
> i would better like to keep code snippets and applications (lappo)
> requiring ldaplib under ldaplib.

IMHO packages of the module distributions should be kept small.
Well, simple demos could be integrated into the modules but not
larger applications.

> else an user will download the C
> module and demos only and then write us the the demos do not work...

A simple table listing which modules are needed by a specific demo
or application helps with that problem. It's just a matter of proper
docs and it's really simple in this particular case (there won't be
so many different demos and applications, I guess).

> > 6. Distributing with Python's standard lib (low priority):
> 
> i don't agree on that.

Any good reason why?

> distribution makers like redhat or debian will
> bundle python-ldap anyway.

But think of e.g. a Win32 distribution, FreeBSD ports or Python on
AS/400. Up to now there are no package maintainers for those
platforms. If python-ldap's modules are integrated into the Python
distribution it makes life *much* easier on all platforms. Well,
it's just a low-priority goal to be reached during the next year.

> ah! and Win2000 Active Directory is not
> compatible with standard ldap...

There are different scopes of compability with LDAP. But that's
another story probably off-topic here.

Ciao, Michael.

Re: Roadmap for ldapmodule

[<fo...@mi...>]

Scavenging the mail folder uncovered Michael Ströder's letter:
> Federico Di Gregorio wrote:
> > i would better like to keep code snippets and applications (lappo)
> > requiring ldaplib under ldaplib.
> 
> IMHO packages of the module distributions should be kept small.
> Well, simple demos could be integrated into the modules but not
> larger applications.
> 
> > else an user will download the C
> > module and demos only and then write us the the demos do not work...
> 
> A simple table listing which modules are needed by a specific demo
> or application helps with that problem. It's just a matter of proper
> docs and it's really simple in this particular case (there won't be
> so many different demos and applications, I guess).

true. it is fine for me. (as long as David agrees.)

> > > 6. Distributing with Python's standard lib (low priority):
> > 
> > i don't agree on that.
> 
> Any good reason why?

not really. but maintaining a package inside a bigger one, that works
on multiple platforms not widely available to the software author is
not an easy task. but that's David's problem, right?

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
          The reverse side also has a reverse side.  -- Japanese proverb

Re: Roadmap for ldapmodule

[Michael <mi...@st...>]

Federico Di Gregorio wrote:
> 
> > > > 6. Distributing with Python's standard lib (low priority):
> > >
> > > i don't agree on that.
> >
> > Any good reason why?
> 
> not really. but maintaining a package inside a bigger one, that works
> on multiple platforms not widely available to the software author is
> not an easy task. but that's David's problem, right?

But triggering all package maintainers is not an easy task either.
It's not even an easy task to know them all.

Ciao, Michael.

Re: Roadmap for ldapmodule

[David L. <dav...@cs...>]

yep. the current CVS directory structure is indeed clumsy. it got that way
i think because some bad decisions were made (by me) early on, and with CVS, 
it is hard to rename directories. (i dont seem to have shell access to the
sourceforge machine with the CVS repository otherwise I would do a mv or six!)

i think using Python's own source tree structure as a basis would be best.
michael's proposed structure is quite similar to this in semantics, and I
liked it. renaming his to become consistent with Python's tree you get:

	Demo/
	Doc/
	Lib/
	Module/

where Module/ contains .c files, Lib/ contains .py libraries, Demo/ contains
some sample apps and Doc/ contains .tex files for documentation. This seems
really reasonable to me.

Also I really don't think that this is the right place for applications.
unless you carefully describe such application as convenient ldap libraries :)
(which is what the core of fog's gtk code could possible be described as.)
otherwise, apps should be independent efforts (not too hard with sourcefogre)
or kept in the Demo/ directory.

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Re: Roadmap for ldapmodule

[Michael <mi...@st...>]

David Leonard wrote:
> 
> i think using Python's own source tree structure as
> a basis would be  best.
> 
>         Demo/
>         Doc/
>         Lib/
>         Module/

Ack. Looks reasonable. Let's do it!

> Also I really don't think that this is the right place for 
> applications.

Ack. I regarded lappo as application - one can regard it as demo.
E.g. I would *not* want to add web2ldap into python-ldap's tree.

Ok, what about the rest of the roadmap?

Ciao, Michael.

Re: Roadmap for ldapmodule

[David L. <dav...@cs...>]

On Thu, 27 Jul 2000, Michael Ströder typed thusly:

> > i think using Python's own source tree structure as
> > a basis would be  best.
> Ack. Looks reasonable. Let's do it!

ok. (any objections from anyone else?)

> Ok, what about the rest of the roadmap?



> 1. Module names (high priority):
> --------------------------------
> Please, rename _ldap back to ldap and rename Fog's stuff to

no, the ldap.py wrapper lib is sufficient.

> 2. CVS (high priority):
> -----------------------
discussed already

> 3. Release of C-module (high priority):
> ---------------------------------------
> AS SOON AS POSSIBLE
agreed! (after 2)

> 4. SSL (medium priority):
> -------------------------
> it's worth looking at OpenLDAP 2.0's new API because this will be
> the new standard API for LDAP.

you are right.  but I feel like waiting until OpenLDAP 2.0 is actually 
released. 
if existing netscape libs have ldap (i think i started downloading it 
yesterday.. but to where?) then that should certainly be supported

> 5. LDAPObjects (low priority):
> ------------------------------
> We have to review Fog's work (hopefully I have the time!) to
> establish a standard Pythonish, re-usable and robust class library
> for LDAP applications.

i would like see a more general X.500 directory class and have 
objectClasses more tightly coupled with python classes. that would be cool.
it might also be cool to wrap LDAP as a db

> 6. Distributing with Python's standard lib (low priority):
> ----------------------------------------------------------
not likely

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Re: Roadmap for ldapmodule

[<fo...@mi...>]

Scavenging the mail folder uncovered David Leonard's letter:

> > 5. LDAPObjects (low priority):
> > ------------------------------
> > We have to review Fog's work (hopefully I have the time!) to
> > establish a standard Pythonish, re-usable and robust class library
> > for LDAP applications.
> 
> i would like see a more general X.500 directory class and have 
> objectClasses more tightly coupled with python classes. that would be cool.
> it might also be cool to wrap LDAP as a db

give a look at .../ldaplib/ldap/schema. you'll find objectClasses and
attributes encapsulated as python classes. they do nothing at now but
the code in schema is already able to ask a v3 compatible server and
build the full classes/attributes/syntaxes tree.

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
  99.99999999999999999999% still isn't 100% but sometimes suffice. -- Me