Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 49159 invoked from network); 6 Dec 2006 18:35:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Dec 2006 18:35:28 -0000 Received: (qmail 55361 invoked by uid 500); 6 Dec 2006 18:35:35 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 55283 invoked by uid 500); 6 Dec 2006 18:35:34 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 55192 invoked by uid 99); 6 Dec 2006 18:35:34 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Dec 2006 10:35:34 -0800 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=MAILTO_TO_SPAM_ADDR,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of akarasulu@gmail.com designates 64.233.184.235 as permitted sender) Received: from [64.233.184.235] (HELO wr-out-0506.google.com) (64.233.184.235) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Dec 2006 10:35:22 -0800 Received: by wr-out-0506.google.com with SMTP id i21so194899wra for ; Wed, 06 Dec 2006 10:35:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:mime-version:to:subject:content-type:sender; b=SmAmymzZQnJlFXm3mGpnjX7VTRoRfNDlbHnZyjZFp5RfPCN1kYxZVTkqIDiSE/Wr7oXWZdRonSBXJLye4ryQvqNELCNVetMmmxCGtYlD/kLG1f2J/RinJUzzUyzoD5SUSIHny2PTI4xdOvfIBViSkNpvY8TyiD+Xuy26nu/+1qA= Received: by 10.100.7.18 with SMTP id 18mr844835ang.1165430101733; Wed, 06 Dec 2006 10:35:01 -0800 (PST) Received: from ?172.16.1.7? ( [65.80.200.112]) by mx.google.com with ESMTP id g3sm580852wra.2006.12.06.10.35.00; Wed, 06 Dec 2006 10:35:01 -0800 (PST) Message-ID: <45770D5A.7000102@apache.org> Date: Wed, 06 Dec 2006 13:35:06 -0500 From: Alex Karasulu Reply-To: akarasulu@apache.org Organization: Apache Software Foundation User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: Apache Directory Developers List Subject: Convo on IRC about schema Content-Type: multipart/mixed; boundary="------------090401050502010600030003" Sender: Alex Karasulu X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------090401050502010600030003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, This was a convo about schema info on IRC. My buffer does however cut some of the conversation. Alex :) not a big deal ok even with OID you cannot have two different OID with same names so each partition has its own subset of the common schema you know this list of names each entity can have like cn and commonName for example yeah you can't reuse cn for something else you should have only one cn in the world like you have only one 2.5.4.5 Let me do X.500++ in my new thesis :) yeah, good idea :) exactly ok, so what were we talking about at the beginning ? we came here from need of parsers let say we have only one partition, cn=example,dc=com alex was explaining that we would use them in two places ahhh, yes, the parsers so we need those parsers so having parsers will be used if a partition admin (or somebody allowed to modify the partition schema) want to add a new AT or OC for not only the description syntaxes defined by the protocol but we're going to add new description syntaxes we're going to add one for each of the following : comparators normalizers syntaxCheckers these descriptions will have either a FQCN value in it (for built in entities bundled with ADS) or a BYTECODE value (base 64 encoded) in it the funny thing is that ifyou have to create a new SC, these will be used to store user added schema constructs that need bytecode to be loaded from them you will have to write a java class for it yeah this is for new SC yeah and calssload it into ADS exactly well this mechanism can be used you could use this for extended OpenLDAP file format too btw and then, you may generate the schema data out of the class :) for instance, for a SC, all you need is : - the SC OID, this way though we completely describe all the elements needed for describing a new schema and the SC description well not really elecharny listening? guys i need to go offline for ph.d bullshit yep np bye ersiner cul8r elecharny let me clarify ... we will keep this convo and post it to you ersiner oh thanks really. bye. <-- ersiner has quit ("Ex-Chat") We want to be able to dynamically load a newly added SC without having to restart the server right? yes someone adds a new schema they add normalizers and comparators and SCs with it yes so we want it so this shit is loaded immediately into memory and a SC is instantiated and added to it's registry so it is made available yes and can be seen via cn=schema at least yes if not by other partition specific subentries so we need to invent a new description syntax for these entities (SC, N, and C) for example ... ( 1.2.34.32.2.21 BYTECODE '12341ab8923c09efa932' ) this can be an SC for example for checking for correct social security numbers for example make sense? another representation may be ... you already have these descriptions in RFC 4517 ( 1.2.34.32.2.21 FQCN org.apache.directory.server.schema.SocialSecuritySyntaxChecker ) ah, sorry, no ok no no this is specific to ADS yeah my bad we're extending schema this way to allow dynamic changes no LDAP server on the market can do this yeah yeah yeah i.e. to make SUN DS do this you have to write your own plugins for it and restart it ok but then, what I said is that so we will have 100% extendible and dymamic schema shoot as soon as you inject this ( 1.2.34.32.2.21 BYTECODE '12341ab8923c09efa932' ) object ahha where the bytecodes represent the compiled java class ahha then you can extract out of it all the information regarding the SC exactly (if these bytcodes is a SC compiled class) so no more need to inject the SC for that yeah we will do verification at the point this new syntaxCheckers attribute value is added because we can generate them on the fly too yeah exactly let me explain to see if we are on the same line ok listening for instance, we want to inject the BooleanSyntaxChecker object (ok, it's already existing, but suppose we are creating it) well this is a built in ok ok np we will compile the BooleanSyntaxChecker.java producting some bytecode aha yep and we will inject it into ADS yep now, you have : ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) which is the definition of the Boolean SC in RFC 4517 yeah this is the syntax not the SC ;) (yes, but let me ficnish ;) this a value in the syntaxes attribute ok what I mean is that now, you can read the compiled class using introspection, extract it's OID (which is stored, and suppose we also added a desc member we can extract the desc field, ahha and inject into cn=schema this Boolean Syntax well I see what you're thinking we have just built from the bytecode take a step back for a second so no need to have a Syntax Checker Parser, because we have injected the binary object hmmm from which we will be able to regenrate this SC syntax ok, stepping back well you're mixing a few things together let me clarify this picture first a SC is not a Syntax looking at the protocol way to add schema elements sorry, I was talking about syntax definitions you cannot add a new syntax to the syntaxes attribute unless you have a SC for that syntax but technically you could just generate the syntax once you have the SC yes but this is mixing up two steps this is what I had in mind hmmm let me think so you add the SC and that automatically generates the Syntax for that SC let's go back to basic is this what you mean? you want to inject an entry wait don't go forward let's not mix up concepts ok sorry you're mechanism is a good idea that can basically reduce a 2 step process into a 1 step process so instead of adding a SC then adding a S you just add an SC this is what you mean? what I wanted to say is that when you describe a new attributeType, you have to describe the syntax it must respect for instance, the attributeType : and use reflection to determine all the info for the Syntax like it's DESC value etc ? yeah yeah now you are mixing into AT stuff ok this will confuse us more let's finish SC verses S concept first IMHO this shit is very complex I just wanted to say that you NEED to know the Syntax OID before using it in an AttributeType yeah which means ...\ you must add the syntax before you can add the AT yeah but this is another subject correct unreated to what we are currently discussing true now SC vs. S I think this shit is complex and confusing just wanted to be clear, but I'm just moving the mud :) ok. let's not take shortcuts or overload meanings let's be mechanical about it so in a standard approach, you first declare the S, and then load the SC hmmm no you first do SC then do S SC btw use OID of the S SC does not have it's own OID this is how the association takes place so you must declare S before SC if Sc use S :) not really SC is just the implementation remember S depends on SC in the object relationship sense yeah a Syntax object has a handle on the SC so S comes first :) Syntax is a valid schema object with DESC and all the other stuff well here's how we simplify it you add SC first then S you cannot add an S to the server before the SC here is why let me explain it has to do with the protocol ahhh we cannot change the S syntax because this is mandated by the protocol I get it right? I'm talking about specs, you are talking about loading those guys into ADS in this way, I agree well I'm talking both you first load SC, and then you declare S I am constrained by many things you're not thinking about at this point let me explain its important I want you to have this in mind fully basically ... (1) protocol demans a certain syntax for syntaxDescriptions and we cannot change this (2) We cannot just add a new syntax using the protocol's representation with a syntaxDescrition because it's not a functional representation of a syntax. Meaning we cannot do anything with ( 1.23.4.2 DESC 'blah blah blah' ). The server cannot check values with just this string. It needs a syntaxChecker object associated with this syntax to functionally enforce this new syntax. yes, I know that. So SC must be added before an S can be added. If someone adds an S and there is no SC for the OID of that S then the server must reject that add. because the server cannot enforce that syntax yes this is why we have this break up of S and SC ok. but the strange thing about the protocol, is taht it defines a syntax for S, because of both protocol limitations and the need to allow for protocol based syntax updates that extend the server but does bnot explain how to add a new S :) yeah the protocol sucks exactly not a big deal, thoough protocol was not even remotely aware of how to dynamically change the code of the server the guys who wrote it did not know about Java :D let say it will be meaningfull for exposing the S when you request the schema yeah exactly people will see that a syntax is defined for it ok. At this point, we agree that if we can introspect SC, we can generate S we can but IMHO this is bad I recommend absolutely no shortcuts or overloading of actions or meanings for simplicity this stuff is too complex leave it so user must load SC then load S or load both at the same time do you agree ? ok not a big deal, though you may not in which case we can discuss it we can ask the user to load SC then S it's not really a PITA well hopefull we let LDAP studio do this I just tried to see if we can avoid one of those two steps if it works with elcipse you can design and write your java SC yes and then LS will load it for u into live server sure LS can make it seem like one step really for me I am looking to keep all functionality simple ok not overloaded with meaning I agree the point is that then you will need thos efucking parsers :) yeah it's ok the string is simple (and I wanted to avoid writting them ;) ok. we just have to implement those parser in syntaxCheckers, well we need either an SC or S parser where they are described in RFC 4517 if we overload if not then we can write parsers for both S and SC we don't have to write a SC parser I recommend doing it for both the syntax of these descriptions are really simple yeah we do we need to write S and SC the SC is the implementation no we need it because user can add a SC via the subentry but what will be the SC syntax then ??? ( 1.12.3.21.3 BYTECODE '23aae23a543bc343' ) for example ahhh, it's OUR syntax yeah ok ok ok there will be two forms I thought you were talking about one existing RFC syntax one for existing classes in the server that come packaged with ADS like so ... ok, I agree. man, I have to go. ( 1.12.3.21.3 FQCN org.apache.directory.server.XYZSyntaxChecker ) for example can you copy/paste all this interesting convo and send it to the list ? so one uses FQCN and other uses BYTECODE --------------090401050502010600030003 Content-Type: text/x-vcard; charset=utf-8; name="akarasulu.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="akarasulu.vcf" begin:vcard fn:Alex Karasulu n:Karasulu;Alex org:Apache Software Foundation;Apache Directory adr:;;1005 N. Marsh Wind Way;Ponte Vedra ;FL;32082;USA email;internet:akarasulu@apache.org title:Member, V.P. tel;work:(904) 791-2766 tel;fax:(904) 808-4789 tel;home:(904) 808-4789 tel;cell:(904) 315-4901 note;quoted-printable:AIM: alexokarasulu=0D=0A= MSN: aok123@bellsouth.net=0D=0A= Yahoo!: alexkarasulu=0D=0A= IRC: aok=0D=0A= PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4 014A 3662 F96F 4E13 70F8=0D=0A= x-mozilla-html:FALSE url:http://people.apache.org/~akarasulu version:2.1 end:vcard --------------090401050502010600030003--