directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Shared refactoring : what's going on, some feedback
Date Sun, 23 Jan 2011 10:06:10 GMT
Hi guys,

as you noticed, some heavy code refactoring is going on in shared. Let 
me give you some feedback about what is being done, and the reasons for 
those refactoring.

First of all, the idea is to release a shared/LdapAPI 1.0-M1 asap. It 
will be LdapAPI from this point, and not anymore shared. This will be a 
milestone, but it will also be a first step toward the exposed API. When 
we will come with a 1.0-RC1, the API will have to be frozen. That being 
said, let's see where we are going to :

- base class renaming. You can see that Alex changed DN to Dn, etc. The 
rational behind those renamings is that it's consistent with the name 
scheme we use : caml humps all over the code. We have a DnParser class, 
and a DN class, which is not consistent. All in all, we discussed those 
names back in september, and if you really feel that DN is better than 
Dn, we can revert, but I thik it's not really a technical issue, much 
more a choice to make. To me, it's not an issue at all.

- API/SPI separation : most of what Alex is doing right now is about 
hiding implementation from the exposed API. The less classes exposed, 
the less problem we might have with users using the SPI classes. ALso 
consider that the API documentation will be more tight.

- OSGi : shared has been completely OSGified, and it's a good thing. We 
have postponed this task year after year, but we reached a point it was 
to be done. One of the reason was that refactoring shared without 
impacting Studio was impossible, because Eclipse dos not allow a project 
to 'see' shared as a dependent source project, so we had to propagate 
the changes manually, something we don't want to do anymore. With the 
OSGi bundles, studio is now directly impacted by shared refactoring 
without any need to do it by hand. Plus OSGi is the best way to manage 
dependencies, and for shared, it cost almost nothing to switch to OSGi 
(well, it took one day). I also do think that after shared refactoring, 
we have to go for Apacheds.

At the end of the day, the refactoring should be finished soon (maybe 
one or two more days). It may create new sub-modules, which may be 
gathered later, not a big deal. Just keep an eye at what is being done, 
if you disagree, feel free to express your opinion.

One important point is that we are using a c-t-r mode (commit then 
review) and not a r-t-c, and I think we don't want to switch to a r-t-c 
at this point of the project :). Committing is not for ever, you can -1 
one commit, it's not an insult to the one who did the commit. I repeat, 
-1 a commit is not an insult. Just be rational, and express your 
technical vision when you -1 something.

All in all, at first I was quite conservative, but I realized that we 
probably need some fresh perspective, because we are all so deeply 
involved that we don't have anymore a 10K feet vision necessary to see 
what's wrong and what's good. It's a good timing now that the API is 
stable to review it, shake it and make it better.

Guys, I engage you to look at what Alex is doing when it will be done, 
and express your opinion then. I think this is one unique opportunity to 
move away from a local minimum to the next stable state.

Thanks !

Emmanuel L├ęcharny

View raw message