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 <[email protected]>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
