[Twisted-Python] ldaptor feedback

[Tommi Virtanen]

On Wed, Jul 02, 2003 at 08:07:48AM +0000, Clark C. Evans wrote:
> | 	LDAP is not really used commonly enough to bloat the twisted
> | 	core with it. (Quick! Name three end user applications using
> | 	LDAP!)
> I think LDAP is pretty cornerstone to any internet application
> where 'single sign on' and other directory information is 
> required.   If it was available, I even picture game servers
> or muds using it... 

	You mean you hope it will be? (Quick! Name three end user
	applications using LDAP!)

	LDAP is an ugly, broken, horrible non-unixy non-internetty
	protocol conceived by the folk who gave you such marvels as
	X.25. I hope LDAP dies screaming.

	On the other hand, I need something to do the things LDAP
	is used at. And, for now, it seems the evolution path
	goes through first implementing LDAP, and then improving it
	(witness the LDAPv3 effort).

> Although the legal environment for open source moves quite slowly,
> it is certainly not static; thus changes may be required down the
> road (think 5-15 years) and furthermore, to enforce the license you
> have to have an coordinated entity to do this.   If the code comes
> from a hodge-podge of developers, most of whom can't be contacted,
> it makes enforcement impossible.

	We'll have bigger problems than Ldaptor's whopping <10
	developers -- and that's an optimistic guess.

> Another problem that is on the horizion is is alot of FUD and
> uncertainty by corporations in using open source beacuse it is
> hard to track down who owned what modules, etc.   Unless we do
> this in an organized manner, it doesn't matter what license
> we put at the top of the file; wide spread adoption will be
> hindered.  Alas, this is probably the wrong list for this sort
> of discussion; perhaps we need a twisted-legal (for licensing, 
> and other legal stuff)

	Count me out. I just don't give a damn. I'm not trying
	to sell Ldaptor to anyone; I never will.

	Then again, someone may end up buying an installation of
	Ldaptor from me. They just won't know it, and won't care. And
	that's the difference.

> | 	Yes, the word syntax is bad. It dates back to the time I tried to
> | 	make the data in LDAP be manipulatable as Python objects, from the
> | 	days before Twisted.
> | 
> | 	I refuse to name a class "Object". I refuse to name a class
> | 	"Proxy".
> 
> After reading the RFC, it seems that "entry" is most often used
> to mean an object in the LDAP database.

	I'm guessing you won't be happy even after an
	s/LDAPObject/LDAPEntry/g operation, so I'm not
	doing that right now.. It doesn't really matter
	what those classes are called, as you aren't
	supposed to really ever instantiate them yourself.

> Right.   And I'd just like to see the opposite:
> 
>         1.  state machine
> 
>              ldaptor.protocols.ldap3.client
>              ldaptor.protocols.ldap3.server
>       
>         2. wire format
> 
>              ldaptor.protocols.ldap3.wire.ber
>              ldaptor.protocols.ldap3.wire.request

	Pureber and pureldap should be applicable to all LDAP versions
	and LDAP over UDP. Pureber should be applicable to all BER-based
	protocols, such as SNMP. They have a broader scope than a
	single protocol.

> | > Anyway, I'm curious how open you are to these items.   Adding this to
> | > Twisted (with alot of work) is probably a good bargin; you get more
> | > eyes helping your project along, documentation, etc.  
> | 	I have long hoped for some other developers to share the work.
> I'm a painful one.  ;)

	Umm. "Yes." Let's see if you write code or docs that are
	worth it ;)

	Questioning me is fine. (Resisting me is futile ;)

> | 	But no, I will not donate >10000 lines of my work to glyph.
> | 	I'm too much a free software bigot; I want to force him to
> | 	the rules of LGPL. Just like everyone else. In fact, that's
> | 	why I still consider him to have a partial copyright on Ldaptor,
> | 	even though he wrote none of it; that makes _me_ faithful to
> | 	the LGPL, too. And that's a good thing.
> I will let Glyph respond to this when he has time.  I do think that
> there is quite a deep mis-understanding here, hopefully this will
> resolve it self shortly.

	I think glyph understands my stand well enough, and we have
	talked about this back when the transition happened.

	There's no way around it. For what is in the Twisted core,
	he wants to have freedoms the LGPL doesn't give him. I don't
	want to donate expected ~30000 lines of python away just
	like that; I want to make him be bound to LGPL, just like
	everyone else.

> Also, I think that you are completely wrong about LDAP not
> being core.  It is just a matter of time.   LDAP is barely
> 6 years old now...  it takes at least 5 years for broad 
> adoption... more like 10.   LDAP has a long way to go, and
> something like ldaptor in twisted could make it go much
> further.   Further, having ldap in twisted will allow other
> packages to tightly integrate with ldap (for instance, the
> imap server via cred), etc.

	Let me repeat myself. If installing one library is too
	much effort for you, you are using the wrong OS.

	Twisted can integrate with LDAP just fine. There's no
	problem in using Ldaptor in the optional parts. There's
	no way to make LDAP ever be a _requirement_ for some
	core Twisted service -- I'll scream bloody murder and
	remove the code, even if that means someone revoking
	my commit access. LDAP is not a pretty protocol, and
	it's too far from minimal to be ever acceptable in
	such a role.

	(Oh, did you notice that the openldap library is not
	in the libc?)

	Besides, if you think makin IMAP authenticate via LDAP
	requires changes in cred _or_ Twisted, you have misunderstood
	how modular Twisted is. I have long had an LDAP-using
	cred mechanism (of course with the old API).

	In fact, most "servers" in Twisted (more like example
	code) only know how to authenticate against in-memory
	data structures. And that's how it's supposed to be.
	I don't want to see Twisted become a hodge-podge of
	100 applications; Twisted should be the _framework_.
	Application code should be external to it. See e.g.
	CVSToys, BuildBot, etc.

-- 
:(){ :|:&};: