[Twisted-Python] ldaptor feedback

[Clark C. Evans]

Hello Tommi.   Thank you for taking time to respond.

On Wed, Jul 02, 2003 at 09:35:20AM +0300, Tommi Virtanen 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... 

| >     Long term I'd like to see Glyph form some sort of non-profit to 
| >     hold the copyrights, or at the very least present a 'will' of 
| >     sorts describing what happens to the copyrights in the event 
| >     that he is incapacitated or gets hit by a MAC truck.    For 
| >     now, I'm not too worried about this.
| 
| 	I think we as the community don't need anything better than
| 	LGPL.

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.

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)

| > 2.  Your package hierarchy needs help... lots of help.
| 
| 	Agreed.

Cool.

| 	The current situation looks more like
| 
| 	from ldaptor.protocol.ldap import ldapsyntax
| 
| 	o = ldapsyntax.LDAPObject(..)

Ok.   

| >     First, ldaptor has one protocol... ldap.  So "protocols.ldap" is
| >     quite redundant.
| 
| 	There's likely to be LDAPv4. LDAP protocol versions aren't really
| 	compatible.

All the more reason to not prefix in class names. ;)

   from ldaptor import ldap3 as ldap
   ent = ldap.client(...)

   // 3 years from now

   from ldaptor import ldap4 as ldap
   ent = ldap.client(...)


And hopefully the interface can be the same, if not, it will
raise an error.   (ie, there may be xtra constructor arguments 
available in ldap4.Entry

| 	What's really making you grit your teeth is that the mechanism
| 	an LDAP client uses to open a connection to an LDAP server should
| 	be in ldaptor.client; and it will be, once I have a clear idea
| 	what the API should look like.

Yes!  And sorry that the griding teeth is so visible.  ;)

| 	from ldaptor import client
| 
| 	d=client.openDN('dc=example,dc=com')
| 	d.addCallback(lambda o: o.search('cn=foo'))

Nice.  

| 	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.  

| >     The 'low-level' pureber and pureldap are really not protocol
| >     items so much as they are parsers/emitters.  You could stuff
| >     these, as well as the filter, ldif, and schema all into 
| >     another part of ldaptor, ldaptor.parse.ldif, etc.
| 
| 	There are two things in a protocol:
| 
| 	1. the wire representation of things
| 		ldaptor.protocols.pureber
| 		ldaptor.protocols.pureldap
| 
| 	2. the state machine
| 		ldaptor.protocols.ldap.ldapclient
| 		ldaptor.protocols.ldap.ldapsyntax
| 
| 	The wire representation of the LDAP messages is never
| 	written to a file, so there's no use for it outside of
| 	the protocol scope.

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

| 	Filter and ldif need to move some day. They started life
| 	as residing inside the neighbouring .py files, and were
| 	split out when they grew too big; moving them should be
| 	reasonably trivial.

Ok.

| > 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.  ;)

| 	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.  

| 	Oh, by the way, you are horribly naive for thinking that
| 	merely having the code located in the Twisted CVS makes
| 	everyone else maintain it. That just isn't the way things
| 	have happened. LDAP is not a core protocol for most people.

Well.  Since flow has been added (to the sandbox), I've received 
over 10 patches, several of them non-trivial and even two that 
extended functionality. I never expected this, but it happened.  
A few patches were even done without asking me (thank god) beacuse
they were so clearly wrong.    This is really the beauty of open
source software; the community does really take ownership of the
code.   I'm not saying that there isn't a primary 'author', but
I am saying that maintanence does get distributed.

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.

Best,

Clark