Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 14648 invoked from network); 2 Nov 2006 15:35:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Nov 2006 15:35:30 -0000 Received: (qmail 67376 invoked by uid 500); 2 Nov 2006 15:35:40 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 67158 invoked by uid 500); 2 Nov 2006 15:35:39 -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 67147 invoked by uid 99); 2 Nov 2006 15:35:39 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Nov 2006 07:35:39 -0800 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of elecharny@gmail.com designates 64.233.162.207 as permitted sender) Received: from [64.233.162.207] (HELO nz-out-0102.google.com) (64.233.162.207) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Nov 2006 07:35:23 -0800 Received: by nz-out-0102.google.com with SMTP id z3so132084nzf for ; Thu, 02 Nov 2006 07:35:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=XyuEAq4JbjK9ua6JkfyteZ57qFGoRsgXWF+nFmXD1TYuS2NtoG3p2LgkgFgxR/22CmAFgk0dZKXQsjPRdTEczY4Zt/LR5rQ4T0lhq0pYS3V1Yv44AZ1KSUz61+vnuBTOo3zQxXbVKbxEuoLAKgKvKZqHTG2hE+EV/tySiA5kFok= Received: by 10.64.208.20 with SMTP id f20mr1011086qbg.1162481702816; Thu, 02 Nov 2006 07:35:02 -0800 (PST) Received: by 10.65.95.7 with HTTP; Thu, 2 Nov 2006 07:35:02 -0800 (PST) Message-ID: Date: Thu, 2 Nov 2006 16:35:02 +0100 From: "Emmanuel Lecharny" Reply-To: elecharny@apache.org To: "Apache Directory Developers List" Subject: Re: ApacheDS partition implementation based on Relational Model In-Reply-To: <20061102144511.11428.qmail@web60725.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6403_13151609.1162481702366" References: <20061102144511.11428.qmail@web60725.mail.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_6403_13151609.1162481702366 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Ole, On 11/2/06, Ole Ersoy wrote: > > Hi Ersin, > > > Personally I need to be able to go between an LDAP > format, XML Schema format, and a relational format. This will be possible really soon, at least from ldap to XML. Pam is writting a DSML codec, so you will be able to extract data from LDAP and put them in XML format (using DSML V2). You will also be able to send data to a ldap server using DSML. I'm planning on going with need a 4th representation > of > those 3, which will be Eclipse EMF Ecore (A subset of > OMG's meta object facility). > > That way ecore is the common denominator. At this point, I really think that DSML might be the perfect pivot description, because LDIF is only representing data while DSML can express operations. For instance, if you want to write a LDAP proxy, you can do that with DSML requests and response (and the LdapStudio ldap browser is working this way, so, yes, this is possible :). I don't think we need a 4th description meta-stuff :) KISS, bros ! So the initial thinking is that ldap attributes will > be mapped to attributes on an Ecore based model object > (Just a pojo really supported by the Eclipse EMF API). > > The same Ecore model is used to generate the Hibernate > mapping (Preferably using annotations). > > Then it's done. Hibernate takes care of the rest. Well, this is a vision which is not taking into account the performance issues you will have if you do that. I may be wrong - and I hope to be, because this seems to be _so_ simple that I really want it to work -, but as an old programmer, I don't believe in god or in 'snap your finger and the tool will do the rest' thingy ... Yeah, I'm an agnostic old fart ;) Make me believe in it : I want a working sample ! I still need to put this in complete context, adding > in Alex's thoughts on virtual directories, etc. > > That's a little off though...after the rpm mojo gets > done. Yeah, that's seems pragmatic :) Thanks for the work done on RPM, man ! Cheers, > - Ole Emmanuel ------=_Part_6403_13151609.1162481702366 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Ole,

On 11/2/06, Ole Ersoy <ole_ersoy@yahoo.com> wrote:
Hi Ersin,

<snip/>
Personally I need to be able to go between an LDAP
format, XML Schema format, and a relational format.
This will be possible really soon, at least from ldap to XML. Pam is writting a DSML codec, so you will be able to extract data from LDAP and put them in XML format (using DSML V2). You will also be able to send data to a ldap server using DSML.
 

I'm planning on going with need a 4th representation
of
those  3, which will be Eclipse EMF Ecore (A subset of
OMG's meta object facility).

That way ecore is the common denominator.

At this point, I really think that DSML might be the perfect pivot description, because LDIF is only representing data while DSML can express operations. For instance, if you want to write a LDAP proxy, you can do that with DSML requests and response (and the LdapStudio ldap browser is working this way, so, yes, this is possible :). I don't think we need a 4th description meta-stuff :) KISS, bros !

So the initial thinking is that ldap attributes will
be mapped to attributes on an Ecore based model object
(Just a pojo really supported by the Eclipse EMF API).

The same Ecore model is used to generate the Hibernate
mapping (Preferably using annotations).

Then it's done.  Hibernate takes care of the rest.

Well, this is a vision which is not  taking into account the performance issues you will have if you do that. I may be wrong - and I hope to be, because this seems to be _so_ simple that I really want it to work -, but as an old programmer, I don't believe in god or in 'snap your finger and the tool will do the rest' thingy ... Yeah, I'm an agnostic old fart ;) Make me believe in it : I want a working sample !

I still need to put this in complete context, adding
in Alex's thoughts on virtual directories, etc.

That's a little off though...after the rpm mojo gets
done.

Yeah, that's seems pragmatic :) Thanks for the work done on RPM, man !

Cheers,
- Ole

Emmanuel

------=_Part_6403_13151609.1162481702366--