Q about some LDAP API data structure

[Emmanuel Lecharny <el...@gmail.com>]

I have some doubt.

yesterday, I created two new sub-projects, ldap-client and 
kerberos-client. Ldap-client project depends on shared and apacheds, and 
is supposed to contain the new LDAP API.

That being said, I have an issue when dealing with data structure like 
Control. It's being used by the client and by the server, but I have to 
decide where to put it : in shared or in ldap-client.

My first impression was hat it should be part of the ldap-client 
project, but then we can't manipulate many of the internal shared 
classes depending on Control (like LDIF classes). On the other hand, I 
can put in in shared, but suddently, it makes the ldap API users' life 
miserable, as they now have to deal with two dependencies.

I'm now thinking that we should go way farther, and move to ldap-client 
many more than just a few classes, keeping in shared just the bare 
minimal classes common to all the projects. We also have to create a 
ldap-server project depending on ldap-client and shared, in order to 
provide the strict minimal API for clients.

At this point, I'm holding my work and wait for some insight from the 
team, before going any further.

Not that it will take weeks to reorganize, but just to make sure all our 
bases are covered.

So waiting for your thoughts, guys !

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com

Re: Q about some LDAP API data structure

[Alex Karasulu <ak...@gmail.com>]

I think we should cleanup shard and the package organization there then look
at this problem with a clear view.  Shared is just in shambles with the way
the packages are organized having been grown out the way it has as the
server needed it and as studio needed it and various other initiatives we've
had.

Don't know if you have time for this though but I think it will lead you to
better clarity.

Best Regards,
Alex

On Mon, Jan 25, 2010 at 11:20 AM, Pierre-Arnaud Marcelot <pa...@marcelot.net>wrote:

> Hi Emmanuel,
>
> On 25 janv. 2010, at 00:41, Emmanuel Lecharny wrote:
>
> > I have some doubt.
> >
> > yesterday, I created two new sub-projects, ldap-client and
> kerberos-client. Ldap-client project depends on shared and apacheds, and is
> supposed to contain the new LDAP API.
> >
> > That being said, I have an issue when dealing with data structure like
> Control. It's being used by the client and by the server, but I have to
> decide where to put it : in shared or in ldap-client.
> >
> > My first impression was hat it should be part of the ldap-client project,
> but then we can't manipulate many of the internal shared classes depending
> on Control (like LDIF classes).
>
> +1, and I think that everything should be gathered inside the same package
> name for clarity. Moving back and forth in packages names between the
> client-api and shared is not very pleasant from a user POV.
>
> > On the other hand, I can put in in shared, but suddently, it makes the
> ldap API users' life miserable, as they now have to deal with two
> dependencies.
>
> You're right, although it could be easily fixed by providing a complete
> "shaded" jar containing all the client and it's dependencies, as we're
> already doing for the apacheds-all artifact. But that won't fix the problem
> of various packages names (o.a.d.shared.* vs o.a.d.ldapclient.* [or whatever
> the package name is]).
>
> > I'm now thinking that we should go way farther, and move to ldap-client
> many more than just a few classes, keeping in shared just the bare minimal
> classes common to all the projects.
>
> I think that's the way to go, and I'm also thinking that maybe LDIF should
> be part of the client API.
> I've seen a lot of friends around me that wanted an easy way to read and
> handle LDIF records for their integration with their app.
> Maybe it would be good to not restrict the client API to the LDAP protocol
> only, but also include a way to read/write/manage LDIF file/record.
>
> Regards,
> Pierre-Arnaud
>
>
> > We also have to create a ldap-server project depending on ldap-client and
> shared, in order to provide the strict minimal API for clients.
> >
> > At this point, I'm holding my work and wait for some insight from the
> team, before going any further.
> >
> > Not that it will take weeks to reorganize, but just to make sure all our
> bases are covered.
> >
> > So waiting for your thoughts, guys !
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.nextury.com
> >
> >
>
>


-- 
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org

Re: Q about some LDAP API data structure

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

Hi Emmanuel,

On 25 janv. 2010, at 00:41, Emmanuel Lecharny wrote:

> I have some doubt.
> 
> yesterday, I created two new sub-projects, ldap-client and kerberos-client. Ldap-client project depends on shared and apacheds, and is supposed to contain the new LDAP API.
> 
> That being said, I have an issue when dealing with data structure like Control. It's being used by the client and by the server, but I have to decide where to put it : in shared or in ldap-client.
> 
> My first impression was hat it should be part of the ldap-client project, but then we can't manipulate many of the internal shared classes depending on Control (like LDIF classes).

+1, and I think that everything should be gathered inside the same package name for clarity. Moving back and forth in packages names between the client-api and shared is not very pleasant from a user POV.

> On the other hand, I can put in in shared, but suddently, it makes the ldap API users' life miserable, as they now have to deal with two dependencies.

You're right, although it could be easily fixed by providing a complete "shaded" jar containing all the client and it's dependencies, as we're already doing for the apacheds-all artifact. But that won't fix the problem of various packages names (o.a.d.shared.* vs o.a.d.ldapclient.* [or whatever the package name is]).

> I'm now thinking that we should go way farther, and move to ldap-client many more than just a few classes, keeping in shared just the bare minimal classes common to all the projects.

I think that's the way to go, and I'm also thinking that maybe LDIF should be part of the client API.
I've seen a lot of friends around me that wanted an easy way to read and handle LDIF records for their integration with their app.
Maybe it would be good to not restrict the client API to the LDAP protocol only, but also include a way to read/write/manage LDIF file/record.

Regards,
Pierre-Arnaud


> We also have to create a ldap-server project depending on ldap-client and shared, in order to provide the strict minimal API for clients.
> 
> At this point, I'm holding my work and wait for some insight from the team, before going any further.
> 
> Not that it will take weeks to reorganize, but just to make sure all our bases are covered.
> 
> So waiting for your thoughts, guys !
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.nextury.com
> 
>